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.La pr6sente invention concerne un procede et un dispositif de 
communication d'information. 

Elle s'applique, en particulier, a un reseau a commutation 
asynchrone de paquets, permettant notamment d'interconnecter un petit nombre 
d'equipements multimedia, tout en leur foumissant differentes qualites de service 
pour echanger des donnees. 

Le comportement d'un trafic de donnees genere par un equipement 
multimedia (ou application) peut s'inscrire dans deux classes de service 
principales, elles memes divisees, chacune, en deux sous-classes. Ainsi le trafic 
peut etre soit elastique (il s'adapte facilement aux changements de conditions de 
transmission), soit temps reel. S'il est elastique, il peut soit etre de nature 
interactive, et done sensible au delai de transfert, soit correspondre a un transfert 
massif d'un gros volume de donnees et done sensible a la bande passante. S'il 
s'agit d'un trafic temps reel, soit il est acceptable de perdre certains paquets 
d'information pour privilegier le delai de transmission, le trafic est alors appele 
"deterministe", soit il est preferable de disposer d'un debit moyen mais sans perte 
de donn6es, le trafic est alors appele "garanti". 

Le trafic elastique correspond au trafic de type datagramme. Ce 
trafic est dit elastique car il est capable de s'adapter aux conditions de 
transmission sans pour autant perdre de son utilite. Un transfert de fichier pourra 
aussi bien s'executer via un chemin supportant un debit de 64 kilobit par seconde 
que via un chemin supportant un debit de 2 Megabit par seconde. Pour le trafic 
elastique, une premiere classe de base concerne le trafic genere par les 



2 



applications interactives ou transactionnelles (comme une application de type 
client-serveur), et une seconde classe identifie les donnees vehiculees par bloc 
(comme le transfert de fichiers). 

Les equipements generateurs d'un trafic temps reel requierent un 
service deterministe ou garanti. Pour le trafic deterministe, qui privilegie le respect 
d'une contrainte elevee en ce qui conceme le delai de transmission, I'application 
qualifie la bande passante dont elle suppose avoir besoin, ainsi que le delai 
maximal de transmission qu'elle peut accepter. Le reseau privilegie ce type de 
trafic mais se debarrasse des donnees pour lesquelles le delai ne peut etre 
respecte. II s'agit par exemple de transmission video (en cas de problemes de 
transmission, une image statique apparaTt), ou de systemes audio de qualite 
moyenne. 

Le service dit garanti se differencie du service deterministe par le fait 
que le reseau ne se debarrasse pas volontairement des donnees issues d'un 
trafic garanti mais que celui ci peut etre affecte d'un delai de transmission variable 
en fonction du trafic deterministe plus prioritaire ou au trafic garanti concurrent. II 
s'agit, par exemple, du trafic video haute definition (utilisant des techniques de 
compression). Dans ce cas, le reseau reserve la bande passante a I'application 
qui requiert un service garanti, mais pour gerer les problemes de gigue (en 
anglais "jitter 11 ) sur les donnees a la reception, I'application doit posseder des 
capacites de stockage temporaires des donnees (de Pordre de la seconde de 
trafic), afin de retablir le comportement original du trafic. 

La garantie de la qualite de service exigee par des applications 
concurrentes et de natures differentes passe par la resolution de problemes tels 
que la gestion des ressources et le controle de trafic. Les precedes a mettre en 
oeuvre doivent permettre au reseau de fonctionner de fagon optimale tout en 
fournissant une qualite de service acceptable aux differentes applications. Ce 
probleme a fait I'objet de nombreuses etudes pour les reseaux a commutation de 
circuits et pour les reseaux a commutation de paquets. 

Dans les reseaux & commutations de circuits, la solution connue 
consiste a allouer a chaque connexion une bande passante constante (canal) 
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pendant toute sa duree. Au prealable, une procedure d'acceptation d'appel 
permet au reseau de savoir s'il peut supporter I'appel. Dans le cas ou aucun canal 
n'est disponible, I'appel est rejete. 

Dans les reseaux a commutation de paquets ou le trafic est, par 
5 definition, imprevisible, la nature variable des debits offre I'opportunite d'un 
partage statistique des ressources du reseau. Cette optimisation des ressources 
augmente, malheureusement, les risques de congestion. Ces reseaux peuvent 
etre vus comme une succession de files d'attente a capacite limitee dont il 
convient de controler le remplissage afin d'eviter leur saturation, synonyme de 
1 0 perte de paquets. 

II est connu de controler le trafic par un mecanisme dit "de 
fenetrage" : lorsqu'un etat de saturation est detecte, le recepteur demande 
explicitement a la source de reduire son flux. On parle alors de regulation et de 
controle de flux. 

1 5 Aucune de ces approches n'est suffisante, la premiere parce qu'elle 

conduit a un gaspillage inevitable des ressources du reseau en allouant a la 
source une bande passante correspondant a son debit maximal et la seconde 
parce que le rapport du temps de propagation sur le temps de transmission 
augmente de maniere considerable lorsque les liaisons sont a tres haut debit. 

20 Dans les systemes de controle de flux par retroaction, entre Tinstant d'emission de 
la notification de congestion et Pinstant de sa reception par le noeud source, le 
trafic deja en transit dans le reseau peut etre considere comme definitivement 
perdu en raison de la congestion, a moins de disposer de memoires de grande 
capacite pourconserver tous les paquets en transit pendant I'etat de congestion. 

25 Par consequent, pour la commutation rapide de paquets, les 

methodes de controle purement reactives sont insuffisantes dans un 
environ nement haut d6bit. La commutation n§cessite des mecanismes 6labores 
dans les 6quipements de commutation (noeuds intermediaires du reseau) incluant 
des methodes preventives et des methodes reactives. La technologie ATM 

30 ("Asynchronous Transfert Mode" ou mode de transfert asynchrone), propose des 
techniques de gestion de la qualite de service, et de controle de congestion 
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basees sur des mecanismes elabores implementes au sein des equipements de 
commutation. Des exemples de tels mecanismes sont decrits dans les brevets US 
5,291,481 et US 5,313,454 qui illustrent aussi la complexity et le cout potentiel 
d'implementation de telles methodes. 

Ces methodes ne sont done pas adaptees a des r&seaux 
comprenant un nombre plus restreint d'equipements a interconnecter ou le cout 
des moyens de communication ne doit pas etre trop eleve par rapport au cout des 
equipements a interconnecter. 

Des tentatives d'utilisation de commutateurs ATM embarques ont 
ete faites, telles que celle decrite dans la these "Architecture distribute temps r6el 
fondee sur ATM" de Jean-Frangois Guilaud (INPG). Cette these mentionne 
Tutilisation de la signalisation ATM classique afin de permettre la gestion des 
connexions, ce qui represente une implementation cornplexe. Cependant, la mise 
en oeuvre complete des mecanismes de gestion des connexions doit prevoir 
d'eviter la congestion, qui, afin de simplifier I'utilisation du commutateur, reposent 
sur une gestion locale des informations de charge et sur I'utilisation des files 
d'attente en sortie pour chaque commutateur. 

Le controle de flux strict, a la source, tel qu'H est decrit dans la 
these, prevoit Tutilisation d'un mode connecte uniquement, et verifie le non 
depassement du transfert de donnees par rapport a ce qui a ete prevu lors de 
I'etablissement de la connexion correspondante. Cela peut done engendrer une 
mauvaise utilisation des ressources reseau ainsi qu'un manque de flexibilite du 
systeme. 

Par ailleurs, il n'est envisage aucun moyen simple pour reagir au 
probleme de congestion si ce n'est en se reposant sur les solutions decrites 
precedemment, propre a Tutilisation de I'ATM, mais qui demeurent des solutions 
complexes. 

De plus, Tutilisation d'une dimension de paquet fixe, conformement 
a TATM, engendre une perte fixe du debit utile par lien du reseau disponible. En 
revanche, une taille de paquet variable en fonction de la charge du reseau permet 
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d'optimiser le debit utile. Les techniques de controle de la taille des paquets ont 
deja ete testees sur des architectures reseau de type bus ou anneau. 

La commutation asynchrone de paquets, telle que decrite dans la 
norme IEEE-P1355, est basee sur une technologie de commutation (matrice de 
5 commutation non bloquante permettant plusieurs chemins simultanes) a faible 
cout de realisation en ce qui concerne le commutateur. En effet, le commutateur 
en question n'utilise qu'un minimum de ressources pour effectuer la commutation 
d'un paquet a partir d'un port d'entree vers un port de sortie. Le transfert d'un 
paquet au travers du commutateur a lieu des que le commutateur a connaissance 
1 0 des informations de commutation du dit paquet (en-tete de paquet) sans attendre 
la complete reception de toutes les donnees du paquet. II n'y a done aucune 
gestion de file d'attente ou de priorite dans les noeuds intermediates du chemin. 

Par ailleurs, afin de regler les problemes de contention d'acces a un 
port d'entree (respectivement vers un port de sortie) du commutateur, lorsque 

15 plusieurs paquets sont a priori destines a transiter via ce port d'entree 
(respectivement de sortie), un mecanisme de controle de flux au niveau du lien 
est implements, n'autorisant une source a transmettre des donnees sur la ligne de 
transmission que lorsqu'elle a obtenu I'autorisation de la part de la destination, 
e'est-a-dire lorsqu'un groupe de donnees precedemment emises par la source ont 

20 ete acquittees par la destination. 

Cependant, la commutation asynchrone de paquets, telle que 
connue dans Petat de la technique, si elle laisse envisager des couts 
d'implementation attractifs, ne prevoit pas de garantir differentes qualites de 
service pour les trafics concurrents au sein d'un meme reseau. 

25 Les technologies de type bus serie proposent une alternative 3 

Tutilisation de la commutation de paquets pour interconnecter des peripheriques a 
moindre cout. En effet, les mecanismes mis en oeuvre pour partager les 
ressources se trouvent simplifies du fait de Tunicite de la ressources principales, 
en Toccurrence le medium de communication. Cette simplicite implique aussi 

30 Tinconvenient d'une bande passante limitee : la bande passante moyenne 
disponible par terminal diminue en fonction du nombre de terminaux connectes. 
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Certaines technologie bus serie, telles que celle normalisee par 
riEEE, reference P1394, definie pour interconnexion d'equipements multimedia, 
supportent le transfert des donnees selon principalement deux classes de service 
en mettant en oeuvre une architecture logique de type bus. Des mecanismes sont 
done necessaires pour arbitrer Tacces au bus et organiser le transfert des 
donnees. Cette technologie de bus serie prevoit un mecanisme de reservation de 
ressources. II permet, d'une part, la transmission de donnees dite isochrone, 
comprenant une phase de reservation, et, d'autre part, la transmission de 
donnees dite asynchrone, sans phase de reservation. 

Le document US-A-5,61 5,254 decrit une methode pour construire 
des tables de routage comprenant, pour chaque paire de noeuds, un chemin 
direct et plusieurs chemins de secours, ainsi que pour mettre & jour 
periodiquement ces tables en fonction d'information de charges. II n'effectue 
cependant pas de choix a priori d'un chemin sur la base d'information effective 
sur la charge, ce qui permet d'ameliorer le rendement du processus de controle 
d'admission des connexions. 

Le document US-A-5,649,108 d6crit I'inconvenient d'utiliser un 
routage a la source sans connaissance a priori sur la charge du reseau et 
propose done le re-routage par certains noeuds qui, eux, ont une connaissance 
de cette charge. Cependant le routage a la source reste plus efficace lorsque la 
source elle-meme a une connaissance sur la charge effective. 

L'invention vise a permettre, sur un reseau a commutation de 
paquets, d'une part, d'effectuer un controle d'admission des connexions, selon un 
chemin defini a la source, sur la base d'information representatives de la charge 
du reseau associee a toutes les connexions actives, et d'autre part, de mettre a 
jour les tables de charges independamment de la connaissance de chaque noeud 
(calcul de parametres de transmission en fonction du service requis, effectue par 
chaque noeud). 

L'invention propose d'ameliorer cet art anterieur pour un r6seau & 
gestion de chemin a la source. A cet effet, la pr6sente invention propose, en 
particulier, de mettre en oeuvre : 
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- des moyens de signalisation qui permettent des echanges pendant 
la phase d'etablissement (par des messages de format specifique qui permettent, 
d'une part, a chaque noeud d'indiquer les besoins de ses applications, besoins qui 
torment des parametres fixes, et, d'autre part, a chaque noeud voisin d'etre 

5 informe des besoins des applications, par des messages de format specifiques), 

- des moyens de selection de chemin (constitues d'une table de 
charge), dans chaque noeud source, qui lui permettent de determiner le chemin a 
faire suivre a chaque message qu'il a a transmettre, et 

- les moyens de surveillance de charge (chaque noeud etant 
10 capable de conserver I'information de charge globale sur le reseau, en fonction 

des parametres de trafic, grace a la structure de la table de charge). 

Ainsi, lorsqu'un chemin est disponible, il est alloue a la connexion et 
les conflits sont evites, meme si les tables de charge ne sont pas coherentes, 
grace aux noeuds intermediates. 

15 Ainsi, la presente invention vise, selon un premier aspect, un 

procede de communication sur un reseau, caracterise en ce qu'il comporte, pour 
Petablissement d'une connexion : 

A/ effectuees par un dispositif de communication source 
d'information a transmettre en mode connecte : 

20 - une operation de determination de besoin de bande passante pour 

la transmission de ladite information en mode connecte, 

- une operation de determination d'un eventuel chemin disponible 
pour ladite transmission, en fonction d'informations conservees dans une table de 
charge de chaque lien du reseau, et 

25 - lorsqu'un chemin disponible est determine : 

• une operation de transmission d'une information 
representative dudit besoin de bande passante a 
destination du dispositif de communication suivant sur ledit 
chemin, et 
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• une operation de mise a jour de ladite table de charge des 
liens du reseau, 

- une operation de diffusion a destination d'au moins tous les 
dispositifs de communication en dehors du chemin, d'une information 

5 representative dudit besoin de bande passante, 

31 effectu6es par chaque dispositif de communication intermediate 
sur ledit chemin : 

- une operation de determination de disponibilite dudit chemin, pour 
ladite communication, en fonction d'informations conservees dans une table de 

10 charge de chaque lien du reseau, et 

- lorsque le chemin est disponible : 

• une operation de transmission d'une information 
representative dudit besoin de bande passante, au 
dispositif de communication suivant sur le chemin, et 

15 • une operation de mise a jour de la table de charge des 

liens du reseau, 

CI effectuee par chaque dispositif de communication en dehors 
dudit chemin : 

- une operation de mise a jour d'une table de charge des liens du 

20 reseau. 

Grace a ces dispositions, chaque dispositif de communication du 
reseau conserve une table de charge contenant des informations representatives 
de toutes les connexions deja etablies. II peut done g6rer les transmissions qu'il a 
a effectuer, que ce soit, en mode connecte ou en mode non connecte. 
25 Ainsi, la mise a jour des tables de charge des dispositifs de 

communications est simultanee £ l'6tablissement de la connexion. Ceci entraine 
un meilleur controle de I'admission des connexions. Le choix d'un chemin a done 
moins de chance d'etre errone. 

Selon des caract6ristiques particulieres, au cours de Toperation de 
30 transmission dudit besoin de bande passante § destination du dispositif de 
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communication suivant sur ledit chemin, le dispositif de communication source 
transmet une information representative d'un service requis pour ladite 
transmission en mode connecte. 

Selon d'autres caracteristiques particulieres, le procede tel que 
5 succinctement expose ci-dessus comporte, effectuee par chaque dispositif de 
communication du reseau, une operation de determination de parametres de 
communication d6pendant du service requis, et I'operation de mise a jour des 
tables est effectuee en prenant en compte lesdits parametres. 

Grace a chacune de ces dispositions, chaque connexion est 
10 caracterisee de la meme fagon, par le service requis, pour tous les dispositifs de 
communication du reseau, quelles que soient les contraintes propres a chacun de 
ces dispositifs de communication. En revanche les parametres pourront varier, 
dispositif de communication par dispositif de communication, en fonction de ces 
contraintes propres et des informations a transmettre. 

15 Selon d'autres caracteristiques particulieres, le procede tel que 

succinctement expose ci-dessus comporte, a la fin de la transmission en mode 
connecte : 

- effectuee par un dispositif de communication source d'information 
transmise en mode connecte, une operation de diffusion d'une information 

20 representative du relachement de la connexion, a destination de tous les 
dispositifs de communication du reseau, et 

- effectuee par chaque dispositif de communication dudit reseau, 
une operation de mise a jour d'une table de charge des liens du reseau. 

Grace a ces dispositions, chaque dispositif de communication du 
25 reseau conserve une table de charge contenant des informations repr6sentant 
uniquement les connexions valides, et non les connexions qui ont ete relachees, 
afin d'ameliorer le temps de traitement des mises a jour des tables de charge. 

Selon d'autres caracteristiques particulieres, au cours de 
I'etablissement d'une connexion, I'operation de diffusion a destination d'au moins 
30 tous les dispositifs de communication en dehors du chemin, d'une information 
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representative dud it besoin de bande passante, est effectuee apres que chaque 
dispositif de communication dudit chemin ait effectue : 

- une operation de determination de disponibilite dudit chemin, pour 
ladite communication, en fonction d'informations conservees dans une table de 

5 charge de chaque lien du reseau, et 

- lorsque le chemin est disponible : 

• une operation de transmission dudit besoin de bande 
passante, au dispositif de communication suivant sur le 
chemin, et 

10 • une operation de mise a jour d'une table de charge des 

liens du reseau. 

Grace a ces dispositions, les dispositifs de communication du 
reseau qui ne se trouvent pas sur ledit chemin n'ont a effectuer de mise & jour de 
leur table de charge que si chaque dispositif de communication du chemin a 
1 5 determine que ce chemin est disponible pour la transmission envisagee. En outre, 
pour tous les dispositifs de communication du reseau, les tables de charges 
permettent d'eviter les conflits d'etablissement de connexion. 

Selon d'autres caracteristiques particulieres, le procede tel que 
succinctement expose ci-dessus comporte, au cours de I'etablissement d'une 
20 connexion, effectuee par le dispositif de communication source, une operation de 
determination de Pintegralite du chemin destin6 a etre suivi par rinformation a 
transmettre en mode connecte. 

Selon ces dispositions, le choix du chemin par le dispositif de 
communication source de rinformation a transmettre permet d'am^liorer le temps 
25 d'etablissement d'une connexion. 

Selon un deuxieme aspect, la presente invention vise un dispositif 
de communication sur un reseau, caracteris6 en ce que : 

- il comporte une m6moire adaptee a conserver une table de charge 
contenant des informations relatives 3 la charge de chaque lien du reseau, et 
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- il est adapte, pour I'etablissement cPune connexion destinee a la 
transmission d'information en mode connecte : 

• a determiner un besoin de bande passante pour la 
transmission de ladite information en mode connecte, 

• a determiner un eventuel chemin disponible pour ladite 
transmission, en fonction d'informations conservees dans 
ladite table de charge, 

et lorsqu'un chemin disponible est determine, 

• a transmettre une information representative dudit besoin de 
bande passante, a destination du dispositif de 
communication suivant sur ledit chemin, 

• a mettre a jour ladite table de charge, 

• a d iff user, a destination d'au moins tous les dispositifs de 
communication en dehors du chemin, une information 
representative dudit besoin de bande passante. 

^invention vise aussi un ordinateur, une camera, un telecopieur, 
un appareil photographique, un televiseur, une imprimante, un scanner et un 
lecteur audio/video, caracterises en ce qu'ils comportent un dispositif tel que 
succinctement expose ci-dessus. 

Uinvention vise aussi : 

- un moyen de stockage d'informations lisible par un ordinateur ou 
un microprocesseur conservant des instructions d'un programme informatique 
caracterise en ce qu'il permet la mise en oeuvre du precede de Tinvention telle 
que succinctement expos6e ci-dessus, et 

- un moyen de stockage d'informations amovible, partiellement ou 
totalement, et lisible par un ordinateur ou un microprocesseur conservant des 
instructions d'un programme informatique caracterise en ce qu'il permet la mise 
en oeuvre du proc6d6 de invention telle que succinctement exposee ci-dessus. 

Les caracteristiques preferentielles ou particulieres, et les 
avantages de ce dispositif, de cet ordinateur, de cette camera, de ce 
telecopieur, de cet appareil photographique, de ce televiseur, de cette 
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imprimante, de ce scanner, de ce lecteur audio/video et de ces moyens de 
stockage d'information etant identiques a ceux du procede tel que 
succinctement expose ci-dessus, ces avantages ne sont pas rappeles ici. 

D'autres avantages et caracteristiques de I'invention ressortiront 
5 de la description qui va suivre, faite en regard des dessins annexes dans 
lesquels : 

- la figure 1 represente un reseau de noeuds interconnects, 

- la figure 2 represente un dispositif (ou "rnoyen") de 
communication selon la presente invention, 

10 - la figure 3 represente des echanges de messages intervenant 

entre un noeud source et un noeud destinataire pour vehiculer d'une part un 
trafic connecte et, d'autre part, un trafic non connecte, 

- la figure 4 represente un organigramme mis en oeuvre par le 
rnoyen de communication du noeud dit "source" pour une transmission en 

1 5 mode connecte, 

- la figure 5 represente un organigramme mis en oeuvre par un 
rnoyen de communication d'un noeud dit "intermediaire" pour une transmission 
en mode connecte, 

- la figure 6 represente un organigramme mis en oeuvre par un 
20 rnoyen de communication d'un noeud dit "destinataire" pour une transmission 

en mode connecte, 

- la figure 7 represente un organigramme mis en oeuvre par un 
rnoyen de communication d'un noeud dit "voisin" pour une transmission en 
mode connecte, 

25 - la figure 8 represente un reseau sur lequel circulent des 

messages de controle destines a la gestion du mode connecte, 

- la figure 9 represente la structure de messages de controle 
destines a la gestion du mode connecte, 

- la figure 10 represente la structure de donnfees d'une table de 
30 charge en memoire d'un rnoyen de communication, 
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- la figure 11 represente la structure de donnees d'une table de 
specifications et de priorites contenant des canaux virtuels reserves a la 
transmission en mode connecte, en memoire d'un moyen de communication, 

- la figure 12 represente un organigramme d'emission en modes 
5 connecte et non connecte d'un moyen de communication tel qu'illustre en figure 2, 

- la figure 1 3 represente un organigramme de determination, par le 
noeud source, de disponibilite de chemin pour I'etablissement d'une connexion, 
incorpore dans Porganigramme de la figure 4, 

- la figure 14 represente un organigramme de determination, par un 
10 noeud intermediate ou le noeud destinataire, de disponibilite de chemin pour 

I'etablissement d'une connexion, incorpore dans I'organigramme de la figure 5 ou 
6, et 

- la figure 15 represente un organigramme de determination, par un 
noeud voisin, de disponibilite de chemin pour I'etablissement d'une connexion, 

1 5 incorpore dans I'organigramme de la figure 7. 

Dans toute la presente demande les termes "dispositifs de 
communication " et "moyen de communication" ont la meme signification et 
designent les memes combinaisons de moyens objets de la presente invention. 

Le mode prefere de realisation gere trois classes de service 
20 specifiques, deterministe (en mode connecte), garantie (en mode connecte) et 
elastique (en mode non connecte), sur un reseau a commutation de paquet. 

En figure 1, on observe cinq equipements multimedias 101 a 105 
d'un reseau a commutation de paquet 100, relies entre eux par six liens 106 a 
111. Chaque equipement multimedia comporte un moyen de communication 
25 112 et un moyen de traitement de donnees 113. Le moyen de communication 
112 permet au moyen de traitement 113 d'ouvrir une connexion d6di6e £ un 
trafic connecte (trafic temps reel deterministe ou garanti) puis de g6nerer ce 
trafic, ou bien de generer directement un trafic non connecte (trafic elastique). 

Lorsque I'equipement multimedia 101 envoie un paquet de 
30 donnees a I'equipement multimedia 105, par I'intermediaire des liens 108 et 
110, Tequipement 101 est un noeud "source", I'equipement 105 est un noeud 



14 



"destinataire", I'equipement 102, par lequel transitent les donnees, est un noeud 
"intermedia ire", tandis que les noeuds 103 et 104 sont des noeuds "voisins", 
aucune des donnees transmises ne transitant par Tun d'entre eux. 

Le mode de realisation decrit et represents concerne un r&seau 
5 local compost de plusieurs noeuds interconnectes par des liens bidirectionnels 
rapides. Chaque noeud incorpore un commutateur non bloquant poss6dant une 
matrice de commutation a reception et emission simultanees (en anglais "cut- 
through crossbar") et possede un certain nombre de ports externes auxquels 
peuvent etre raccordes des liens. Dans un tel reseau, la route ou le chemin 
10 suivi par un paquet est une succession de liens, chacun des liens etant defini 
par les deux noeuds qu'il rejoint. 

La communication sur un tel reseau est dite "commutee". Un 
exemple d'un tel reseau est donne par un systeme utilisant des composants 
selon la norme IEEE 1355. 

15 En figure 2, on observe un schema bloc d'un moyen de 

communication 1 12 du reseau, comportant un composant commutateur/routeur 
209 couple a une unite centrale 206 (decomposee en deux entites 206A et 206 
B). 

Le composant commutateur/routeur 209, constitue d'un 
20 composant de la marque SGS-THOMSON (marque deposee), reference ST 
C104, comporte des ports physiques relies a un connecteur 230, et deux ports 
internes dont Tun est dedie au controle, relics a I'unite centrale 206 par 
Tintermediaire de differents composants decrits ci-dessous. 

On observe ici que le composant commutateur/routeur 
25 susmentionne 209 ST C104 possede, en fait, trente-deux ports physiques en 
plus de deux ports de controle, seulement un port de controle et quelques ports 
physiques etant representes en figure 2. Des composants d'interface 213 et 
216 sont relies aux deux ports internes du composant commutateur/routeur 209 
et sont, chacun, bases sur un composant reference ST C101 et fabriqu6 sous la 
30 marque SGS-THOMSON. 
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Le composant commutateur/routeur 209 et les composants 
d'interface 213 et 216 effectuent un codage conforme a la norme IEEE 1355. Le 
composant commutateur/routeur 209 est a architecture de type non bloquante. 

Des emetteur/recepteurs, non representes, plus connus sous leur 
5 denomination technique de langue anglaise tt transceiver \ convertissent des 
signaux TTL, sur les ports physiques du composant commutateur/routeur 209 
en signaux differentiels sur le connecteur 230. 

Les emetteurs/recepteurs sont, par exemple, des composants de 
la marque AT&T (marque deposee) references 1141 MK. 

10 Le connecteur 230 est destine a etre relie a plusieurs connecteurs 

identiques incorpores a d'autres moyens de communication du reseau. lis sont 
de la marque deposee HARTING et de reference 2721-121-8000. 

Les composants d'interface 213 et 216 sont relies, par une liaison 
parallele, a une interface PCI 208, elle-meme reliee a un bus PCI 231. 
15 L'interface 208 est, par exemple, composee d'un circuit AMCC (marque 
deposee) S5933. Le bus PCI 231 est, en outre, relie : 

- a un composant d'interface 232, identique au composant 208, lui- 
meme relie au moyen de traitement 113 (figure 1) ; 

- a une interface de controle 203, par exemple constitute d'un 
20 composant 82439 HX de marque INTEL ©, lui meme relie a un bus local d'unite 

centrale 206, comportant un microprocesseur 206A et une memoire cache 
statique 206B, et a une memoire dynamique 204 (constitute des deux entites 
204A et 204 B) ; et 

- a un composant d'interface 205, par exemple de reference 
25 82371 5B de marque INTEL ©, ce composant etant relit a un bus ISA qui relie 

un controleur ISA de peripheriques 233, a une memoire flash de systeme 
d'exploitation BIOS 234, S une horloge temps-reel 235 et a une extension de 
memoire flash 236. 

L'architecture et les composants du moyen de communication 112 
30 sont bien connus de I'homme du metier des systemes informatiques et ils ne 
sont pas plus detailles ici. 
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Pour une meilleure comprehension de la constitution du mode de 
realisation decrit et represents, le lecteur est invite a consulter les notes 
d'utilisation des composants, notes fournies par leurs constructeurs respectifs. 

L'unite centrale de traitement CPU 206 est compos6e d'un 
5 microcontroleur 206A de la marque d6posee INTEL et de ref6rence PENTIUM 
(marque d6posee) avec 32 Mo de memoire vive dynamique DRAM 204 a titre 
de memoire de travail, 256 Ko de memoire statique cache 206B. 

On observe ici que I'expression "segment de memoire" utilisee ci- 
dessous designe, dans chacune des m6moires, aussi bien une zone memoire 
10 de faible capacite (ne conservant que quelques donnees binaires), qu'une zone 
memoire de grande capacite (permettant de stacker un programme entier). 

La memoire vive 204A conserve des donnees, des variables et 
des resultats intermediates de traitement utilises par les programmes stockes 
en memoire 204B, dans des segments de m6moire portant, dans la suite de la 
1 5 description, les memes noms que les donnees dont ils conservent les valeurs. 

En cours de fonctionnement, la memoire flash 204B contient le 
BIOS et les logiciels de controle (qui operent avec le systeme d'exploitation 
temps-reel CHORUS (marque deposee)) qui sont decrits en figure 3 a 7. 

La memoire vive 204 comporte notamment : ^ 
20 - un segment de memoire " user_data " dans quel sont 

conservees les informations utilisateur a transmettre, dont, en particulier, le 
service requis (comportant la bande passante necessaire), 

- un segment de memoire " addjdata " dans lequel sont conservees 
des informations additionnelles a transmettre, informations qui definissent, 

25 notamment, dans son integralite, le chemin a suivre par les donnees utilisateur 
sur le reseau de communication (figure 9), et 

- un segment de mdmoire " Tables " dans lequel sont conserv6es 
une table de charge de chemins et une table de charge de liens comportant des 
informations decrivant tous les chemins dont le noeud consider^ est la source 

30 et tous les liens faisant partie de ces chemins (figures 1 0 et 1 1 ). 

La zone d'extension de m6moire 236 est adaptee a conserver : 
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- le programme de fonctionnement de I'unite centrale de traitement 
206, dans un segment de memoire " programl ", et 

- un identificateur representatif du moyen de communication 112, 
identificateur qui est unique sur le reseau de communication. 

A Initialisation du moyen de communication, le programme stocke 
dans la memoire d'extension 236 est au moins partiellement copie et organise 
dans la zone memoire d'execution 204B. 

La zone d'extension de memoire 236 constitue un moyen de 
stockage d'informations lisibles par un ordinateur ou un microprocesseur, 
conservant des instructions d'un programme informatique caracterise en ce qu'il 
permet la mise en oeuvre du procede de linvention. Selon une variante, la zone 
d'extension de memoire 236 est amovible, partiellement ou totalement, et 
comporte, par exemple, une bande magnetique, une memoire flash, une 
disquette ou un compact disque a memoire figee ("CD-ROM" en anglais). 

Dans le mode de realisation decrit et represente, le moyen de 
traitement utilise le moyen de communication conforme a I'invention. Le moyen 
de traitement demande I'etablissement d'une connexion au moyen de 
communication en lui faisant part du service requis ("application requirement" 
en anglais). Ces parametres dits de "service requis" sont, d'une part, transmis 
dans certains messages de signalisation et, d'autre part, utilises pour calculer 
les parametres de transmission ("trafic parameters" en anglais). Le service 
requis est I'etalon utilise pour la mise a jour des tables de charges dans les 
differents noeuds du reseau car il ne depend pas de I'etat respectif des tables 
de charges. 

Les organigrammes objets des figures 4 a 7 n'illustrent que 
partiellement le fonctionnement des dispositifs de communication. 

L'unite centrale de traitement 206 est adaptee a mettre en oeuvre 
les organigrammes decrits en figures 4 a 7. 

En figure 3, on observe, symbolises par des fleches descendantes 
placees dans une colonne centrale, des messages transmis sur le reseau, entre 
un noeud source, a gauche, et un noeud destinataire, a droite. Les fleches 



18 



orientees de la gauche vers la droite correspondent a des messages transmis 
depuis le noeud source des donnees utilisateur a destination du noeud 
destinataire de ces donnees et les fleches orientees de la droite vers la gauche 
correspondent a des messages transmis depuis le noeud destinataire des 
5 donnees utilisateur vers le noeud source de ces donn6es. 

Dans la colonne de gauche, sont representes les messages 
echanges entre le moyen de traitement du noeud source (a gauche) et le 
moyen de communication du noeud source (a droite de la colonne de gauche). 
Dans la colonne de droite, sont representes les messages echanges entre le 
10 moyen de traitement ^u noeud destinataire (a droite) et le moyen de 
communication du noeud destinataire (a gauche de la colonne de droite). 

Les six fleches 251 a 256 de la colonne centrale correspondent a 
un mode de communication connecte conforme a la presente invention, les 
fleches 257 et 258 correspondent a une transmission en mode non connecte 
15 avec synchronisation des deux moyens de traitement et la fleche 259 
correspond a une communication en mode non connecte sans synchronisation 
des deux moyens de traitement. 

Dans la colonne centrale, les fleches 254, 257, 258 et 259 
correspondent a des transferts de donnees sur le reseau, les autres fleches 
20 correspondant a des messages organisant ces transferts. 

En mode connecte, c'est-a-dire dans le cas du trafic connecte, le 
moyen de traitement du noeud source informe le moyen de communication du 
noeud source de Pouverture d'une connexion en lui envoyant un message de 
requete de connexion ("connect_req") 

25 En consequence, le moyen de communication du noeud source 

lance la phase d'initialisation ( n set-up n en anglais). Cette phase comporte 
notamment remission d'un message d'initialisation 251 (message "set-up") par 
le moyen de communication du noeud source et a destination du moyen de 
communication du noeud destinataire (par Tintermediaire, le cas ech6ant, du 

30 moyen de communication de chaque noeud intermediate). 
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A reception du message de "sef-up", le moyen de communication 
du noeud destinataire informe le moyen de traitement du noeud destinataire 
qu'il a regu une demande d'ouverture de connexion, par I'intermediaire d'un 
message de demande d'ouverture de connexion "connectJncT. 

5 Si la demande est acceptee, le moyen de communication du 

noeud destinataire est informe par le moyen de traitement du noeud 
destinataire, par I'intermediaire d'un message " connect jans" (identify en figure 
6 par le nom "callRequest_ack" pour acceptation de requete d'appel ou de 
"callRequest_nactf\ pour rejet de requete d'appel, selon le resultat de la demande 
10 d'ouverture de connexion, operations 377 et 378 respectivement. Dans le premier 
cas, un message de connexion 252 ^connect') est emis par le moyen de 
communication du noeud destinataire vers le moyen de communication du 
noeud source. 

Le moyen de traitement du noeud source est alors informe du bon 
15 deroulement de I'ouverture de la connexion par un message de confirmation de 
connexion "connect_cfr'\ de la part du moyen de communication du noeud 
source. Le moyen de communication de chaque noeud du reseau est alors 
informe de I'etablissement d'une nouvelle connexion par I'intermediaire d'un 
message 253 de mise a jour de table de charge "LinkTabLoad" diffuse par le 
20 moyen de communication du noeud source. Ce message est aussi utilise pour 
confirmer aupres des noeuds intermediates et du noeud destinataire le bon 
deroulement de la phase d'etablissement de la connexion. 

Le transfert de donnees composant le trafic connecte associe & la 
connexion, du noeud source vers le noeud destinataire, peut alors avoir lieu. A 
25 cet effet, le moyen de traitement du noeud source et le moyen de 
communication du noeud source echangent des messages de demande 
demission d'un message de donn6es n sendlsoData_req" et de confirmation 
d'emission du message de donnSes "sendlsoData^cfr". 

Le transfert des messages de donnees 254 est alors effectue 
30 apres segmentation du flot de donnees en paquets de taille predefinie. Le 
moyen de communication du noeud destinataire regoit les paquets de donn6es 
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qu'H confie au moyen de traitement du noeud destinataire, par I'intermediaire du 
message de reception d'un message de donnees "sendlsoData^ind"), apres 
avoir restructure le flot de donnees. 

Lorsque les donnees £ transmettre ont ete transmises, le moyen 
5 de traitement du noeud source peut decider de la fermeture d'une connexion en 
transmettant un message de demande de fermeture de connexion 
"release_req" au moyen de communication du noeud source. 

Le moyen de communication du noeud source emet alors : 

- un message de confirmation de relachement "release__cfi* 9 a 
10 destination du moyen de traitement du noeud source, 

- un message de relachement "re/ease" 255 a destination des 
eventuels noeuds intermediaires et du noeud destinataire, et 

- un message 256 de mise a jour de table de charge "LinkTabFree" 
a tous les noeuds du r6seau. 

15 Le message 256 est utilise pour confirmer aupres des noeuds 

intermediaires, des noeuds voisins et du noeud destinataire le bon deroulement 
de la phase de liberation de la connexion. Au niveau du noeud destinataire, le 
moyen de communication informe le moyen de traitement de la fermeture de la 
connexion par I'intermediaire d'un message de notification de fermeture de 

20 connexion "release_incf\ 

Le transfert de donnees pour le trafic elastique, en mode non 
connecte avec synchronisation des moyens de traitement, se fait sans 
ouverture prealable d'un connexion, par la transmission du message d'6mission 
de message n sendSyncData_req" par le moyen de traitement du noeud source 

25 vers le moyen de communication du noeud source. Ce moyen de 
communication effectue le transfert 257 des donnees apres segmentation du 
flot de donnees en paquets de taille pred§finie. Au niveau du noeud 
destinataire, la reception des donnees est effectuee par le moyen de 
communication, qui informe le moyen de traitement, et transmet le flot de 

30 donnees restructur6, par I'usage du message de reception de message 
"sendSyncData_incf \ En r6ponse, le moyen de traitement du noeud destinataire 
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emet, & destination du moyen de communication du noeud destinataire, un 
message de bonne reception n sendSyncData_ans" 9 qui contient la reponse du 
moyen de traitement du noeud destinataire et provoque le transfert d*un 
message 258 entre le moyen de communication du noeud destinataire et le 
5 moyen de communication du noeud source. A reception de ce message 258, le 
moyen de communication du noeud source emet a destination du moyen de 
traitement du noeud source un message de confirmation de transmission 
"sendSyncData^cfr". 

Le transfert de donnees pour le trafic elastique, en mode non 
10 connecte sans synchronisation des moyens de traitement, se fait sans 
ouverture pr^alable d'un connexion, par la transmission du message d'emission 
de message n sendAsyncData_req n par le moyen de traitement du noeud source 
vers le moyen de communication du noeud source. Ce moyen de 
communication effectue le transfert 259 des donnees apres segmentation du 
15 flot de donnees en paquets de taille predefinie et emet a destination du moyen 
de traitement du noeud source un message de confirmation de transmission 
"sendAsyncDatajcft". Au niveau du noeud destinataire, la reception des 
donnees est effectuee par le moyen de communication, qui informe le moyen 
de traitement et transmet le flot de donnees restructure, par Pusage du 
20 message de reception de message u sendAsyncDataJnd\ 

Les figures 4 a 7 illustrent les procedures de gestion des 
connexions selon I'invention. 

En ce qui concerne le moyen de communication du noeud source, 
apres avoir ete dans un etat d'initialisation 300 (figure 4), un message entrant 

25 n connect_req n est regu au cours d'une operation 301 , de la part du moyen de 
traitement du noeud source. Ce message comporte le service requis, dont la 
bande passante, et le mode de transmission. Le moyen de communication du 
noeud source effectue alors la selection d'un chemin allou6 a la connexion, le 
calcul des parametres de transmission en fonction du service requis puis la 

30 mise a jour de la table de charge si un chemin est disponible (figure 13), au 
cours d'une operation 302. 
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Ensuite, au cours d'un test 304, le moyen de communication du 
noeud source determine si la bande passante necessaire a la connexion 
envisagee est disponible sur le chemin selectionne, ou non. Cette procedure de 
test 304 est connue sous le nom de " Controle d'Admission de Connexion " ou 
5 encore "CAC". Lorsque le resultat du test 304 est n6gatif, au cours d'une 
operation 303, le moyen de communication emet un message de refus 
d'ouverture (message " connect jcfi" negatif) de communication a destination du 
moyen de traitement du noeud source. Ce message de refus "connectjcft" 
negatif a pour effet d'avertir Papplication logicielle qui avait requis la 
10 transmission de Pimpossibiiite d'effectuer cette transmission en mode connecte. 

Ensuite, les ressources associees a la gestion de la connexion 

sont liberees. 

Lorsque le resultat du test 304 est positif, au cours d'une operation 
305, le moyen de communication emet le message 251 "set-up" (figure 3) a 
15 destination du moyen de communication du noeud destinataire, par 
Pintermediaire de chacun des dispositifs de communication des eventuels 
noeuds intermediates. Ce message 251 decrit la connexion a etablir (voir figure 
9). 

Ensuite, au cours d'une operation 306, un compteur d'horloge (en 
20 anglais "timer") "cncAckWaif est initialise a une valeur qui correspond & un 
delai maximum accorde a Petablissement de la connexion demandee. Le 
moyen de communication se met alors dans un etat d'attente de la reponse du 
reseau quant a Petablissement de la connexion, etat 307. 

Dans cet etat 307, trois ev6nements differents peuvent se 
25 produire, au cours d'operations 308, 310 ou 31 1 . 

Lorsque, dans Petat 307, le message entrant est un message 
"cncAckWaif, provenant du passage a zero de la valeur du compteur de 
signaux d'horloge "cncAckWaif 1 initialise au cours de Pop6ration 306, operation 
308, ou lorsque le message entrant est un message " release Jback\ provenant 
30 du noeud destinataire ou de Pun des eventuels noeuds intermediaires, 
operation 310, Poperation 323 est effectuee, au cours de laquelle le moyen de 
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traitement du noeud source est inform^ du rejet de la demande de connexion. A 
cet effet, le moyen de communication du noeud source 6met un message 
"openCall_nack", correspondant a un message "connectjcft** n6gatif, notifiant le 
rejet de la connexion, a destination du rnoyen de traitement du noeud source. 

5 A la suite de I'operation 323, au cours d'une operation 324, le 

moyen de communication du noeud source precede a la mise a jour des tables 
de charge associees a la connexion qui a ete rejetee. Puis, au cours d'une 
operation 325, les ressources associees a la gestion de la connexion sont 
liberees. 

10 Enfin, lorsque, dans I'etat 307, le message entrant est un 

message de connexion 252 "connecF, provenant du noeud destinataire, 
operation 31 1, le moyen de communication du noeud source effectue remission 
d'un message d'acquittement d'ouverture de connexion n openCall_ackr, 
correspondant a un message "connect_cf(" positif, a destination du moyen de 

15 traitement du noeud source, operation 312, puis, au cours d'une operation 313, 
diffuse un message 253 "LinkTabLoad" comportant notamment la description 
du service requis, la bande passante utilisee ainsi que la description du chemin 
correspondant a la connexion, en termes de liens. Ce message est diffuse a 
destination de tous les noeuds du reseau, ce qui a pour effet que chaque noeud 

20 du reseau met a jour ses tables de charge. La diffusion de ce message est 
effectuee en suivant un arbre de recouvrement du reseau, determine selon des 
techniques connues (voir figure 8). 

Le moyen de communication du noeud source se met alors dans 
I'etat 314 au cours duquel il attend une evolution de la connexion et transmet 
25 toutes les donnees destinees & etre transmises en mode connecte, sur la 
connexion mise en place. 

Deux messages peuvent alors entrer dans le moyen de 
communication, au cours d'op6rations 315 et 318. 

Lorsque, dans l'6tat 314, le message entrant est un message de 
30 relachement provenant d'un autre noeud du reseau "re/ease^bac/c", operation 
315, le moyen de communication du noeud source 6met un message de 
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terminaison de communication "callTerminate", "release_ind" figure 3, a 
destination du moyen de traitement du noeud source, operation 316, ce qui a 
pour effet d'informer le moyen de traitement de la fermeture de la connexion. 

Puis, le moyen de communication emet un message d'alarme 
5 " alarm jdcnBacK\ operation 317, a destination du moyen de traitement du 
noeud source, ce qui a pour effet de d§clencher le traitement d'une alarme par 
ce moyen de traitement puisque la connexion a ete interrompue de rnaniere 
anormale. Puis, le moyen de communication diffuse a destination de tous les 
autres noeuds du reseau, un message de mise a jour de tables de charges 
10 "LinkTabFree", comportant notamment une description du service requis et du 
chemin correspondant a la connexion, en termes de liens, operation 320. 

Le moyen de communication effectue alors une operation 321, 
identique a I'operation 324, puis une operation 322 au cours de laquelle les 
ressources associees a la gestion de la connexion sont detruites. 

15 Lorsque le message regu, dans I'etat 314, est un message de 

demande de fin de connexion (message "release__req" provenant du moyen de 
traitement du noeud source et message " release jcfr*\ en reponse), operation 
318, le moyen de communication emet un message de relachement 255 
"release", operation 319, puis effectue les operations 320, 321 et 322. 

20 En ce qui concerne chaque noeud intermediaire (figure 5), apres 

avoir ete dans un etat d'initialisation 300, un message entrant 251 "set-up" est 
requ au cours d'une operation 331, de la part du noeud source (voir operation 
305). Le service requis pour la connexion consideree est alors extrait de ce 
message 251 "set-up". Le moyen de communication du noeud intermediaire 

25 effectue alors un calcul des parametres de transmission, a partir du service 
requis, puis, si la charge est acceptable, une mise a jour de ses tables de 
charge, au cours d'une operation 332, d6taill6e figure 14. 

Ensuite, au cours d'un test 335, le moyen de communication du 
noeud intermediaire determine si la bande passante necessaire & la connexion 
30 envisag6e est disponible sur le chemin s6lectionne, ou non (voir test 304). 
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Lorsque le resultat du test 335 est negatif, au cours d'une 
operation 333, le moyen de communication du noeud intermediate emet un 
message de relachement de connexion "release_back? % a destination du noeud 
source (voir operation 310). Puis le moyen de communication du noeud 
5 intermediaire Iib6re les ressources associees a la gestion de la connexion 
consideree, operation 334. 

Lorsque le resultat du test 335 est positif, au cours d'une operation 
336, le moyen de communication emet un message d'initialisation "sef-up" 251 
a destination du moyen de communication du noeud destinataire et de chacun 
10 des moyens de communication des eventuels noeuds intermediaires. Ce 
message est emis apres mise a jour du champ identifiant la position du noeud 
dans le chemin, a partir de la description du chemin en termes de liens (voir 
figure 9). 

Ensuite, au cours d'une operation 337, le compteur d'horloge 
15 "cncAckWaif est initialise a une valeur qui correspond a la duree maximale 
accordee a I'etablissement de la connexion. Le moyen de communication se 
met alors dans I'etat 338 d'attente de la reponse du reseau quant a 
I'etablissement de la connexion. 

Dans cet etat 338, cinq evenements differents peuvent se 
20 produire, au cours d'operations 339, 341, 345, 346 et 347. 

Lorsque le message entrant est un message "cncAckWail", 
provenant du passage & zero de la valeur du compteur de signaux d'horloge 
"cncAckWaif initialise au cours de Poperation 337, operation 339, le moyen de 
communication emet un message de relachement "re/ease", operation 340, a 

25 destination du noeud destinataire et des eventuels noeuds intermediaires qui le 
s6parent du noeud destinataire, et emet un message de relachement 
"release_bacK\ a destination du noeud source et des eventuels noeuds 
intermediaires qui le separent du noeud source, operation 342. Ensuite, au 
cours d'une operation 343, le moyen de communication du noeud intermediaire 

30 considere procede a la mise a jour des tables de charge associees a la 
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connexion qui a ete rejetee. Puis, au cours d'une operation 344, les ressources 
associees a la gestion de la connexion sont liberees. 

Lorsque le message entrant est un message "release" 255, 
provenant du noeud source ou d'un noeud intermediaire entre le noeud source 
et le noeud intermediaire considere, operation 341, le moyen de communication 
effectue les operations 342 a 344. 

Lorsque, dans I'etat 338, le message entrant est un message 256 
"LinkTabFree", operation 347, ce message est memorise et le moyen de 
communication reste dans I'etat 338. 

Lorsque, dans I'etat 338, le message entrant est un message de 
demande de fin de connexion emis par un moyen de controle de noeud, dont la 
fonction est de prendre en compte les differents problemes du reseau, 
operation 346, ce message est memorise et le moyen de communication reste 
dans I'etat 338. 

Enfin, lorsque le message entrant est un message 253 
"LinkTabLoad", comportant notamment la description du service requis, ainsi 
que la description du chemin en termes de liens, en provenance du noeud 
source (voir operation 313), operation 345, le moyen de communication se met 
dans un etat 348 au cours duquel il attend une evolution de la connexion et 
transmet toutes les donnees destinees a etre transmises en mode connects, 
sur la connexion mise en place. 

On observe ici que le message 253 "LinkTabLoad" a, vis a vis 
d'un noeud intermediaire (et du noeud destinataire), pour fonction de confirmer 
I'etablissement de la connexion, au cours de I'operation 345. 

Dans I'etat 348, trois evenements peuvent se produire, au cours 
d'op6rations 349, 350 et 351 . 

Lorsque, dans I'etat 348, le message entrant est un message 256 
"LinkTabFree", operation 351, ce message est memorise et le moyen de 
communication reste dans I'etat 348. 
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Lorsque, dans I'etat 348, le message entrant est un message 255 
"release", Toperation 353 decrite plus loin est effectuee. 

Enfin, lorsque, dans I'etat 348, le message entrant est un 
message de demande de fin de connexion, emis par un moyen de controle de 
5 noeud, operation 350, le moyen de communication emet un message de 
relachement "release_back" a destination du noeud source, operation 352. 

A la suite de Tune des operations 349 ou 352, le moyen de 
communication effectue, au cours d'une operation 353, remission d'un message 
de relachement "release" a destination du noeud destinataire et de chaque 
10 eventuel noeud intermediate qui separe le noeud intermediate considere et le 
noeud destinataire. 

Le moyen de communication effectue alors une operation 354 
identique a I'operation 324, puis une operation 355 au cours de laquelle le 
compteur d'horloge "cncAckWaif est initialise a une valeur qui correspond a la 
15 duree maximale accordee a la liberation de la connexion. Le moyen de 
communication se met alors dans I'etat 356 d'attente de la reponse du reseau 
quant au relachement de la connexion. 

Dans I'etat 356, deux messages peuvent survenir, au cours 
d'operations 357 et 358. 

20 Lorsque le message entrant est un message 256 "LinkTabFree", 

operation 357, les ressources associees a la gestion de la connexion sont 
liberees, operation 360. 

Lorsque, dans I'etat 356, le message entrant est un message 
"cncAckWaif , provenant du passage a zero de la valeur du compteur de 
25 signaux d'horloge "cncAckWaif initialise au cours de l'op6ration 355, operation 
358, le moyen de communication emet un message d'alarme " alarm jdcnTO" % 
operation 359, a destination d'un moyen de controle de noeud, ce qui a pour 
effet de declencher le traitement d'une alarme par ce moyen de traitement 
puisque la connexion n*a pas ete relachee de maniere normale. 
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A la suite de Tune des operations 357 ou 359, les ressources 
associees a la gestion de la connexion sont liberees, operation 360. 

En ce qui concerne le noeud destinataire, (figure 6), apres avoir 
6te dans un etat d'initialisation 370, un message entrant "setUp^end" est regu 
5 au cours d'une operation 371, de la part du noeud source ou d'un noeud 
intermediate. Le moyen de communication du noeud destinataire effectue alors 
1'extraction du service requis, operation 371, puis le calcul des parametres de 
transmission a partir du service requis, et, si la charge est acceptable, la rnise a 
jour de la table de charge, au cours d'une operation 372 similaire a ('operation 
10 332, decrite figure 14. 

Ensuite, au cours d'un test 373, le moyen de communication du 
noeud destinataire determine si la bande passante necessaire a la connexion 
envisagee est disponible sur le chemin selectionne, ou non (voir tests 304 et 
335). 

15 Lorsque le resultat du test 373 est negatif, au cours d'une 

operation 333, le moyen de communication du noeud destinataire emet, a 
destination du noeud source et de tous les eventuels noeuds intermediaires, un 
message de relachement " release JbacK\ au cours d'une operation 380. 
Ensuite, les ressources associees a la gestion de la connexion sont liberees, 

20 operation 382. 

Lorsque le resultat du test 373 est positif, le moyen de 
communication du noeud destinataire emet, a destination du moyen de 
traitement du noeud destinataire un message de demande de connexion 
n connect_incf\ au cours d'une operation 374. 

25 Puis, le moyen de communication se met dans un etat 375 

d'attente de la reponse du moyen de traitement du noeud destinataire. 

Dans I'etat 375, trois tenements peuvent survenir, au cours 
d'operations 376, 377 et 378. Lorsque le message entrant est un message de 
relachement "re/ease", provenant du noeud source ou de I'un des noeuds 
30 intermediaires, il est m6morise au cours de l*op§ration 376. 
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Lorsque, dans I'etat 375, le message entrant est une reponse 
defavorable "callReq_nactf\ correspondant a un message "connect_ans n 
negatif (figure 3), provenant du moyen de traitement du noeud destinataire, 
operation 378 f au cours d'une operation 379, le moyen de communication du 
5 noeud destinataire precede a la mise a jour des tables de charge assoctees a la 
connexion qui a ete rejetee. Puis les operations 380 et 382 sont effectuees. 

Enfin, lorsque, dans I'etat 375, le message entrant est un 
message favorable "callReqjacK\ correspondant a un message "connectjans" 
positif (figure 3), en provenance du moyen de traitement du noeud destinataire, 

10 operation 377, le moyen de communication ernet un message 252 "connect, 
directement vers le noeud source, par mise en oeuvre du moyen de routage, au 
cours d'une operation 381. Ensuite, au cours d'une operation 383, le compteur 
d'horloge "cncAckWaif est initialise a une valeur qui correspond a un delai 
maximum accorde a I'etablissement de la connexion demandee. Le moyen de 

15 communication se met alors dans I'etat d'attente de la reponse du reseau quant 
a I'etablissement de la connexion, etat 384. 

Dans cet etat 384, cinq evenements peuvent survenir au cours 
d'operations 385, 386, 387, 389 et 390. 

Lorsque le message entrant est un message de relachement 
20 "re/ease", provenant du noeud source ou de Tun des noeuds intermediates, ii 
est memorise au cours de I'operation 385. 

Lorsque, dans I'etat 384, le message entrant est un message de 
mise a jour de table de charge 256 "LinkTabFree", provenant du noeud source, 
il est memorise au cours de I'operation 389. 

25 Lorsque, dans l'6tat 384, le message entrant est un message de 

demande de fin de connexion provenant du moyen de traitement ou d f un 
moyen de controle de noeud, il est memorise au cours de I'operation 386. 

Lorsque, dans I'etat 384, le message entrant est un message 
n cncAckWait\ provenant du passage a z6ro de la valeur du compteur de 
30 signaux d'horloge "cncAckWaif initialise au cours de I'operation 383, op6ration 
390, le moyen de communication §met un message de relachement de 
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connexion "release^back", operation 391, a destination des noeuds 
intermediaires et du noeud source. 

Ensuite, au cours d'une operation 392, le moyen de 
communication du noeud destinataire proc^de a la mise a jour des tables de 
5 charge associees a la connexion qui a et6 rejetee. Puis, au cours d'une 
operation 393, les ressources associees a la gestion de la connexion sont 
liberees. 

Enfin, lorsque, dans Petat 384, le message entrant est un 
message 253 "LinkTabLoad', message comportant notamment la description 
10 du service requis ainsi que la description du chemin en terme de liens 
(message ayant pour fonction de confirmer Petablissement de la connexion), 
operation 387, le moyen de communication du noeud destinataire se met dans 
un etat 388 d'attente devolution de la connexion. 

On observe ici que le message 253 "LinkTabLoad" a, vis a vis 
15 d'un noeud intermediate, pour fonction de confirmer Petablissement de la 
connexion. 

Dans Petat 388, trois evenements peuvent survenir, au cours 
d'operations 394, 396 et 397. 

Lorsque, dans Petat 388, le message entrant est un message de 
20 mise a jour de table de charge 256 "LinkTabFree", provenant du noeud source, 
il est memorise au cours de Poperation 396. 

Lorsque, dans Petat 388, le message entrant est un message de 
relachement 255 "re/ease", operation 397, le moyen de communication effectue 
la notification "callTerminate", correspondant a un message " release Jnd* 
25 (figure 3), de la rupture de la connexion au moyen de traitement du noeud 
destinataire, operation 398. Ensuite, Poperation 399 decrite plus loin est 
effectuee. 

Enfin, lorsque, dans Petat 388, le message entrant est un 
message de demande de fin de connexion emis par un moyen de controle de 
30 noeud, operation 394, le moyen de communication emet un message de 
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relachement " release Jback* a destination du noeud source et des noeuds 
intermediaires, operation 395. 

A la suite de Tune des operations 395 ou 398, le moyen de 
communication effectue une operation 399 identique a I'operation 324, puis une 
5 operation 400 au cours de laquelle le compteur d'horioge "cncAckWaiT est 
initialise a une valeur qui correspond 3 la duree maximale accordee d la 
liberation de la connexion. Le moyen de communication se met alors dans Petat 
401 d'attente de la reponse du reseau quant au relachement de la connexion 
de la meme fagon que pour les noeuds intermediaires. 

10 Dans I'etat 401, deux messages peuvent survenir, au cours 

d'operations 402 et 403. 

Lorsque le message entrant est un message 256 "LinkTabFree", 
operation 402, les ressources associees a la gestion de la connexion sont 
liberees, operation 405. 

15 Lorsque, dans I'etat 401, le message entrant est un message 

"cncAckWaiF, provenant du passage a zero de la valeur du compteur de 
signaux d'horioge "cncAckWaiF initialise au cours de I'operation 400, operation 
403, le moyen de communication emet un message d'alarme "alarm_dcnTO", 
operation 404, a destination du moyen de controle de noeud, ce qui a pour effet 

20 de declencher le traitement d'une alarme par ce moyen de traitement puisque la 
connexion n'a pas ete relachee de maniere normale. 

A la suite de Tune des operations 402 ou 404, les ressources 
associees a la gestion de la connexion sont liberees, operation 405. 

En ce qui concerne chaque noeud voisin (figure 7), apres avoir ete 
25 dans un etat d'initialisation 411, le moyen de communication du noeud voisin 
regoit un message 253 "LinkTabLoad", comprenant notamment la description 
du service requis ainsi que la description du chemin en termes de liens, 
operation 412. Ensuite, au cours d'une operation 413, le moyen de 
communication du noeud voisin effectue le calcul des parametres de 
30 transmission a partir du service requis, puis, independamment de la charge, la 
mise a jour de la table de charge. 
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Ensuite, dans I'etat 414, le moyen de communication du noeud 
voisin attend revolution de la connexion. Ensuite, au cours d'une operation 415, 
il regoit un message 256 "LinkTabFree" concernant la connexion, message 
comprenant notamment la description du service requis ainsi que la description 
du chemin en termes de liens. 

Ensuite, au cours d'une operation 416, le moyen de 
communication du noeud voisin precede a la mise a jour des tables de charge 
associees a la connexion qui a ete liberie. Puis, au cours d'une operation 417, 
les ressources associees a la gestion de la connexion sont liberees. 

On observe ici que le message 253 "LinkTabLoad" a, vis a vis 
d'un noeud voisin, pour fonction d'informer sur I'etablissement de la connexion. 

Ainsi la procedure (figure 7) correspond plutot a une notification 
qu'a un controle d'admission. 

En figure 8 sont repr6sent6s, dans un r6seau a commutation de 
paquets 800 : 

- un noeud source 801 , 

- un noeud destinataire 802, 

- deux noeuds intermediates 803 et 804, 

- cinq noeuds voisins 805 a 809, et 

- les liens entre ces noeuds. 

Le long de ces liens sont representes des messages transitant 
successivement sur le reseau ainsi constitue, sous forme de fleches. 

On observe que le message 251 "set-up" circule : 

- du noeud source 801 au noeud intermediaire 803, puis 

- du noeud intermediate 803 au noeud intermediaire 804, puis 

- du noeud intermediaire 804 au noeud destinataire 802. 

En revanche, le message 252 "connect 9 retourne directement du 
noeud destinataire 802 au noeud source 801, sans intervention des noeuds 
intermediates 803 ou 804. Ce message 252 peut, en fait, passer par n'importe 
quel chemin entre le noeud destinataire et le noeud source, par exemple par un 
chemin passant par le noeud voisin 808. 




Enfin, les messages de mise a jour de table de charge 253 
"LinkTabLoad" et 256 "LinkTabFree" sont diffuses a tous les noeuds du reseau, 
en suivant un arbre de recouvrement. 

Preferentiellement, toutes les extremites, ou "feuilles" de I'arbre de 
recouvrement se trouvent sur le chemin de la connexion. Ainsi, lorsqu'il y a une 
panne dans le reseau, les noeuds du chemin, noeuds intermediates ou noeud 
destinataire, qui, comme on I'a vu dans les organigrammes des figures 5 et 6, 
attendent le message "LinkTabLoad" 253, respectivement dans les etats 345 et 
387, peuvent detecter la panne lorsque I'un des noeuds voisins ne transmet pas 
ce message. 

En figure 9, on observe, sur quatre lignes successives, les 
structures des messages 251 "set-up", 255 "release", de mise a jour de table de 
charge, 253 "LinkTabLoad" ou 256 "LinkTabFree" et 252 "connect'. 

Le message 251 "set-up" comporte successivement les champs : 

- 901, ^identification du type de message ("set-up", 
"LinkTabLoad", "LinkTabFree", "Connect ou "Release", voir figure 3), 

- 902, d'identification de connexion, 

- 903, de description de trafic, representatif du service requis, 

- 904, de donnees propres au moyen de communication 
permettant notamment d'identifier les moyens de traitement des noeuds source 
et destinataire, 

- 905. de nombre de liens qui utilisent le chemin associe a la 

connexion, 

- 906, de rang du lien sur lequel transite le message, sur le chemin 
associe a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
correspondant a la connexion souhaitee, et 

- 908, de donnees de protocole. 

Le message 255 "release" comporte successivement les 

champs : 
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- 901, ^identification du type de message ("set-up" , 
"LinkTabLoad", "LinkTabFree", "Connect' ou "Release", voir figure 3), 

- 902, d'identification de connexion, 

- 909, de cause de la demande de relachement, 

5 - 905, de nombre de liens qui utilisent le chernin associe £ la 

connexion, 

- 906, de rang du lien sur lequel transite le message, sur le 
chemin assocte a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
10 correspondant a la connexion souhaitee, et 

- 908, de donnees de protocole. 

Un message de mise a jour de table de charge 253 ou 256 
comporte successivement les champs : 

- 901, d'identification du type de message ("set-up", 
1 5 "LinkTabLoad", "LinkTabFree", "Connect ou "Release", voir figure 3), 

- 902, d'identification de connexion, 

- 903, de description de trafic, representatif du service requis, 

- 910, d'information relative a I'arbre de recouvrement mis en 

oeuvre, 

20 - 905, de nombre de liens qui utilisent le chemin associe a la 

connexion, 

- 906, de rang du lien sur lequel transite le message, sur le chemin 
associe a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
25 correspondant a la connexion souhaitee, et 

- 908, de donn6es de protocole. 

Le message 252 "connect 9 comporte successivement les 

champs : 

- 901, d'identification du type de message ("set-up", 
30 "LinkTabLoad", "LinkTabFree", "Connect 9 ou "Release", voir figure 3), 

- 902, d'identification de connexion, 
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- 911, de donnees de protocole, pouvant etre utilisees par le 
moyen de traitement du npeud source. 

- 908, de donnees de protocole. 

En figure 10, on observe des descripteurs de liens 1001 £ 1007 
disposes cote a cote et des descripteurs de chemins 1011 a 1015 dispos6s sur 
des lignes successives. 

Chaque descripteur de chemin est une structure de donnees pour 
la description d'un chemin qui comporte, en particulier la reference des liens 
impliques dans la description de ce chemin et la reference de chaque 
connexion associee a ce chemin. Chaque descripteur de chemin sortant (101 1 , 
1012 ou 1013) concerne un chemin cree par le moyen de routage du moyen de 
communication. 

Les chemins qui ne partent pas du noeud considere sont dits 
"temporaires" et permettent de connattre les charges des liens des chemins 
sortants. Les chemins temporaires sont crees par le moyen de controle de 
charge qui gere tous les chemins (operations 1307, 1407 et 1504, figures 13 a 
15). 

Dans le mode de realisation decrit et represents, les chemins 
1011, 1012 et 1013 sont des chemins sortants (en traits gras) et les chemins 
1014 et 1015 sont des chemins temporaires (en traits fins). Les chemins 101 1, 
1012 et 1013 decrivent la table de routage et sont utilises par le noeud 
considere pour etablir des chemins vers n'importe quel noeud destinataire. 

Chaque descripteur de lien 1001 a 1007 comporte, en particulier, 
la reference de chaque chemin qui traverse le lien consider^, identifie par un 
rectangle, a Intersection d'une ligne verticale partant du descripteur de lien 
consid6r6 et d'une ligne horizontale partant du descripteur de chemin 
considere. 

Les liens 1001 £ 1004 font partie d'au moins Tun des chemins 
sortants, et sont representes en traits gras. Chaque intersection de deux lignes 
marqu6e par un point represente une reference en memoire : 
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- les lignes externes (en haut et/ou a gauche des rectangles) 
reperent les references conservees avec chaque lien : ces references 
concernent chaque chemin qui traverse ledit lien, et 

- les lignes internes (en bas et/ou a droite des rectangles) reperent 
les references conservees avec chaque chemin : ces references concernent 
chaque lien traverse par ledit chemin. 

La mise a jour de la table de charge effectuee par le moyen de 
controle de charge, comporte les etapes suivantes : 

- pour I'etablissement d'une connexion : 

• mise a jour de la charge de tous les liens references par 
le chemin (ajout de charge), et 

• pour chaque lien, mise a jour de la charge de chaque 
chemin reference pour ce lien ; 

- pour le retrait d'une connexion : 

• mise a jour de la charge de tous les liens references par 
le chemin (deduction de charge), et 

• pour chaque lien, mise a jour de la charge de chaque 
chemin reference pour ce lien ; 

- pour I'ajout d'un chemin : 

• soit par le moyen de routage, lors de I'etablissement de 
la table de routage du noeud considere (il s'agit alors 
d'un chemin sortant), ou lors de la mise a jour de la table 
de routage, 

• soit par le moyen de contr6le de charge, lorsque le 
chemin associe a une nouvelle connexion lors de I'ajout 
de charge n'est pas deja specifie (il s'agit alors de 
chemin temporaire) ; 

- pour la suppression d'un chemin : 

• par retrait d'un chemin temporaire lorsqu'il n'est plus 
traverse par aucune connexion, apres retrait d'une 
connexion, soit lorsque la liste de connexions referencee 
par ce chemin est vide, 
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- pour la transformation d'un chemin sortant en chemin temporaire 
lorsqu'il ne fait plus partie de la table de routage (a la suite d'une operation de 
mise a jour de la table de routage) ; et 

- pour la suppression d'un lien : 

5 • par retrait d'un lien lorsqu'il n'est plus traverse par aucun 

chemin, ou lorsque la liste des chemins references par 
ledit lien est vide. 
Dans la table de charge, a chaque lien est associee une 
information de charge et a chaque chemin est associee une information 
10 representative du lien le moins disponible. Ainsi, la bande passante disponible 
du lien le moins disponible est aussi la bande passante disponible du chemin. 

On observe que c'est en utilisant cette information de disponibilite 
de bande passante de chemin, que le moyen de communication effectue le 
choix du chemin en choisissant le chemin le plus disponible. Pour chaque 
15 information a transmettre en mode non connecte, la disponibilite de chaque 
chemin du reseau est ainsi estimee, en fonction du trafic en mode connecte. 

La charge d'un chemin est definie a partir de son lien le moins 
disponible. II est caracterise par la bande passante totale qu'il autorise et la part 
maximale de la bande passante associee au trafic en mode connecte. Etant 
20 donnee la charge effective du trafic en mode connecte, chaque moyen de 
communication definit la part associee au trafic en mode non connecte, comme 
egale a la bande passante totale a laquelle on a soustrait la part associee au 
mode connect6. 

Le moyen de communication alloue a I'ensemble des 
25 transmissions en mode non connecte qu'il a a effectuer, tout ou partie de la 
bande passante (preferentiellement une partie, pour eviter des probtemes de 
congestion du reseau). Cette part est 6quitablement repartie entre toutes les 
transmissions en mode non connecte et se trouve done dynamiquement mise a 
jour au debut et & la fin de chaque transmission en mode connecte (lorsque la 
30 charge du trafic en mode connecte varie). 
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L'attribution d'une part est effectuee en definissant un plage de 
valeurs du nombre de paquets a emettre entre deux valeurs extremes 
(specjCPmin 1114 et specJDPmax 1115 (figure 11). Cette operation 
d'attribution de bande passante est effectuee avant remission de rinformation 
5 257 ou 259 (figure 3). 

En outre, on considere qu'un chemin qui supporte plus d'un 
nombre predetermine de transmission sortante en mode non connecte n'est 
pas disponible pour une transmission en mode non connecte supplemental. 

Les evenements qui peuvent influencer l'attribution de bande 
10 passante a une transmission en mode connecte sont de deux types : 

- ceux qui concernent le mode connecte, Tetablissement ou la 
fermeture d'une connexion, et qui influent sur la bande passante qui lui est 
reservee, et, par consequent, sur le nombre de paquets a emettre en mode non 
connecte mais aussi sur la faille de ces paquets, et 
15 - ceux qui concernent le mode non connecte, le debut ou la fin 

d'une transmission, et qui influent sur le nombre de paquets a emettre en mode 
non connecte. 

Pour la gestion de la table de charge illustree en figure 10, la 
charge d'un chemin est determinee par la charge du lien le moins disponible, en 
20 prenant en compte, pour la charge d'un lien, la somme des charges des 
chemins qui le traversent. 

Les chemins sortants utilises sont etablis par un moyen de 
routage de type connu. 

On observe ici que chaque noeud du reseau controle le flux qu'il 
25 genere et que rinformation permettant de controler ces flux est etablie a partir 
de la table de charge qui est partagee entre les differents noeuds, chaque 
noeud conservant cette information sous forme d'un tableau tel que celui illustr& 
en figure 1 1 . 

Les niveaux de priorite des messages sont etablis par le moyen 
30 de traitement a partir du service requis. 
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En figure 11, on observe un tableau 1100, comportant trois lignes 
1101, 1102 et 1103, chacune des lignes comportant des specifications de 
canaux virtuels 11 05 a 1110. 

On rappelle ici que chaque canal virtuel est une entite logique 
5 associ6e a une communication entre deux applications mises en oeuvre par 
deux moyens de traitements associes a deux moyens de communication. 

Dans le tableau de la figure 11, on a choisi de representer deux 
canaux virtuels pour chaque niveau de priorite, pour des raisons de clarte. 
Cependant, pour chaque niveau de priorite, le nombre de canaux virtuels peut 
10 varier entre zero a un nombre predetermine. 

Chacune de ces specifications comporte : 

- une information representative de la taille "spec_L" 1111 des 
paquets associes au canal ; 

- une information representative du nombre de paquets a emettre 
15 "spec__CP" 1112 durant Pintervalle de temps primaire considere ; 

- une information representative de ia duree "spec_CV 1113 de 
Tintervalle de temps primaire considere ; 

- une information representative du niveau de priorite (haut, 
moyen ou bas) "spec jprio" 1114 associe au canal ; 

20 - une information "dynJDP" 1117 representative du nombre de 

paquets reellement emis sur le canal virtuel, pendant Tintervalle de temps 
primaire considere ; 

- une information "dyn_CT 1118 representative du nombre 
d'intervalles de temps secondaires ecoules pendant Tintervalle de temps 

25 primaire considere ; et 

- une information "VC_state" 1119 representative de Tetat dans 
lequel se trouve le canal virtuel, 7/6re'\ "acf/f ou "endormr (voir figure 12) ; et 

- une information "references" 1120 representative des positions 
(ou references), en memoire, des donnees utilisateur a transmettre. 

30 En outre, les specifications du niveau de priorite basse 

comportent : 
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- une information "spec_CPmin" 1115 representative de la valeur 
minimale du nombre de paquets a emettre "spec_CP" 1112 - une information 
"spec_CPmak" 1116 representative de la valeur maximale du nombre de 
paquets a emettre "spec_CP" 1112 , ceci afin de permettre de diminuer la 
valeur de "spec_CP" 1112 au cours de I'operation 1221 ou de I'augmenter au 
cours de I'operation 1215, dans la limite de ces bornes spec_CPmin 1115 et 
specjCPmax 1116. 

Enfin, chaque ligne, ou niveau de priorite, est affectee d'une 
information "prio_state n 1120 representative de I'etat dans lequel se trouve 
1'ensemble des canaux virtuels du niveau de priorite considere : lorsqu'au 
niveau de priorite considere ne se trouve aucun canal, le niveau de priorite est 
"libre", lorsque tous les canaux du niveau de priorite sont dans un etat 
"endormr, le niveau de priorite est lui-meme dans un etat "endormf, et dans les 
autres cas, le niveau de priorite est "actif. 

La table de specifications et de priorites 1100 est constitute en 

plagant : 

- en premiere ligne 1101 (niveau de priorite "haut") tous les 
canaux virtuels affectes a des transmissions en mode connecte, ou "temps reel 
deterministe" (en anglais "predictive real time") ; 

- en deuxieme ligne 1102 (niveau de priorite "moyen") tous les 
canaux virtuels affectes a des transmissions en mode connecte temps reel 
garanti (connu sous le nom de temps reel garanti, ou , en anglais, "guaranted 
real time") ; 

- en troisieme ligne 1103 (niveau de priorite "haut") tous les 
canaux virtuels affectes a des transmissions en mode non connecte (connu 
sous les noms de "asynchrone" et "elastique", ou , en anglais "elastic"). 

Ainsi, tous les noeuds disposent d'une table de priorite concernant 
le trafic qu'il peut generer, et chacun s'occupe des messages dont il est la 
source (principe connu sous le nom de "outgoing trafic" en anglais, qui signifie 
"trafic sortant"). 
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On observe ici que les parametres de transmission sont 
determines par le moyen de controle de charge a partir du contenu de la table 
de charge. Par consequent, les parametres de transmission associes aux 
canaux virtuels de haute et moyenne priorite 1 101 et 1102 sont calcules a partir 
5 d'une connaissance, a priori, sur tout le trafic connecte alors que les 
parametres de transmission associes aux canaux virtuels de faible priority 1 103 
sont estimes a partir d'une connaissance limitee au trafic non-connecte sortant 
du noeud consider^. 

La figure 12 represente un organigramme de fonctionnement 
10 d'emission en modes connecte et non connecte d'un moyen de communication 
tel qu'illustre en figure 2. Cet organigramme est mis en oeuvre par I'unite 
centrale 206 (figure 2). 

Le principe du fonctionnement utilise est que I'ordre demission 
des paquets est base sur le remplissage d'un intervalle de temps primaire IT-P, 
15 comprenant des intervalles de temps secondaires IT-S. 

A la suite de I'operation d'initialisation 1201 par remise a zero de 
toutes les variables, un test 1202 determine si un intervalle de temps 
secondaire s'est ecoule, le debut d'un intervalle de temps secondaire etant 
determine a partir de I'horloge temps reel 235. Lorsque le resultat du test 1202 
20 est positif, au cours d'une operation 1203, 1'unite centrale 206 se place en debut 
de la table de specifications et de priorites (figure 11). 

Ensuite, au cours d'une operation 1204, I'information n dyn__CT 
1 1 18 du canal virtuel considere est decrement6e. Puis, au cours d'un test 1205, 
I'unite centrale 206 determine si la valeur de rinformation n dyn_CT' 1118 du 
25 canal virtuel considere est egale a zero, ou non. Lorsque le resultat du test 
1205 est positif, c'est-a-dire a la fin d'un intervalle de temps primaire, au cours 
d'un test 1220, I'unite centrale 206 determine si la valeur de rinformation 
"dynjCP" 1117 est egale a zero, ou non. Le test 1220 correspond done a 
chaque debut d'un nouvel intervalle de temps primaire. 

30 Lorsque le resultat du test 1220 est negatif, au cours d'une 

operation 1221, I'unite centrale 206 gere les priorites de la maniere suivante : 
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- pour le trafic deterministe, priorite haute, les paquets non 
transmis durant Pintervalle de temps requis, dont le nombre est egale a la 
valeur de valeur "dyn_CP' 1117, sont supprimes (perte de paquets) puis, la 
valeur "dynjCR* 1 1 17 est mise a z6ro , et 

5 - pour le trafic garanti, priorite moyenne, les paquets non transmis 

durant Pintervalle de temps sont conserv6s et "dyn_CP l 1117 conserve sa 
valeur, et 

- pour le trafic elastique, priorite basse, la bande passante est 
reduite, par decrementation de la valeur n spec_CP" 1112 dans la limite des 

10 bornes autorisees. 

A la suite de Poperation 1221 ou lorsque le resultat du test 1220 
est positif, une operation 1206 est effectuee. 

Au cours de Poperation 1206, les specifications et parametres de 
transmission sont mis a jour (voir figure 11): 

15 - les informations 1111a 1113 et 1115 a 11 16 sont mises a jour a 

la fin de chaque intervalle de temps primaire, en fonction des changements 
d'etat de la table de charge determine par le moyen de controle de charge, 

- la valeur de reformation "dyn_CP % 1117 est incrementee de la 
valeur de I'information "spec^CP* 1 1 12, 

20 - la valeur de I'information "dyn_CT % 1118 est incrementee de la 

valeur de Pinformation "spec_CV 1113, 

- la valeur de Information "VCjstate" 1119 passe de P6tat 
"endormr a Petat "acf/f. 

A la suite de Poperation 1206 ou lorsque le resultat du test 1205 
25 est negatif, une operation 1207 consiste, pour Punite centrale 206, a considerer 
le canal virtu el suivant dans la table de specifications et de priorites. 

Ensuite, le test 1208 determine si la fin de la table de 
specifications et de priorites a et6 depassee, ou non. Lorsque le resultat du test 
1208 est n6gatif, les operations 1204 & 1207 sont reit6rees. Lorsque le resultat 
30 du test 1208 est positif, c'est-a-dire lorsqu'un intervalle de temps secondaire est 
acheve, un test 1209 determine si la liste des canaux virtuels de niveau de 
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priorite "hauf possede une information d'etat "prio_state n 1120 a la valeur 
"actif ou non. Lorsque le resultat du test 1209 est positif, au cours d'une 
operation 1210, I'unite centrale 206 procede a remission du paquet dont le 
remplissage est effectue a partir du champ reference 1120, qui Indique la 
position memoire des prochaines donnees a emettre, en mode connecte temps 
reel deterministe et procede a la mise a jour des specifications du canal virtuel 
permettant remission du paquet considere : 

- ('information n dyn_CP' 1 1 1 7 est decrementee, 

- si Information n dyn_CP' 1117 est egale a zero, la valeur de 
reformation "VC_state n 1119 prend la valeur "endormr et le prochain canal 
virtuel du meme niveau de priorite est considere et, s'il n'y a aucun autre canal 
virtuel de meme niveau de priorite, le niveau de priorite voit son information 
"prio_state" 1 120 prendre la valeur "endormf. 

L'emission du paquet ne se termine que lorsque le prochain noeud 
intermediaire a acquitte le controle de flux qu'il a opere sur les donnees dudit 
paquet, tel que cela est decrit dans la norme IEEE-1355 et implements par les 
composants ST-C101 213 ou 216 et ST-C104 209. 

On remarque ainsi que les conflits d'acces aux ressources de 
transmission (les liens de communications) sont detectes par le protocole de 
transmission de paquets, par exemple conforme a la norme IEEE-1355. 
L'invention permet done de limiter les effets de ces conflits d'acces pour 
equitablement repartir I'acces aux ressources entre les differents noeuds du 
reseau, tout en garantissant une qualite de service specifiee par le service 
requis. 

Lorsque le resultat du test 1209 est negatif, un test 1211 
determine si la liste des canaux virtuels de niveau de priorite "moyerf possede 
une information d'etat "priojstate" 1120 a la valeur "actif ou non. Lorsque le 
resultat du test 1211 est positif, au cours d'une operation 1212, I'unite centrale 
206 procede a remission d'un paquet en mode connecte temps reel garanti et 
procede a la mise a jour des specifications du canal virtuel permettant 
remission du paquet considere : 
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- I'information "dyn_CP" 1 117 est decrementee, 

- si I'information "dyn_CP' 1117 est egale a zero, la valeur de 
I'information "VC_state" 1119 prend la valeur "endormr et le prochain canal 
virtuel du meme niveau de priorite est considere et, s'il n'y a aucun autre canal 
virtuel de meme niveau de priorite, le niveau de priorite voit son information 
"prio_state" 1120 prendre la valeur "endormr. 

Lorsque le resultat du test 1211 est negatif, un test 1213 
determine si la liste des canaux virtuels de niveau de priorite "bas" possede une 
information d'etat "prio_state" 1 120 a la valeur "actiT ou non. Lorsque le resultat 
du test 1213 est positif, au cours d'une operation 1214, I'unite centrale 206 
procede a remission d'un paquet en mode non connecte et procede a la mise a 
jour des specifications du canal virtuel permettant remission du paquet 
considere : 

- I'information "dyn_CP" 1 1 1 7 est decrementee, 

- si I'information "dyn_Cr 1117 est egale a zero, la valeur de 
I'information "VC_state" 1119 prend la valeur "endormr et le prochain canal 
virtuel du meme niveau de priorite est considere et, s'il n'y a aucun autre canal 
virtuel de meme niveau de priorite, le niveau de priorite voit son information 
"prio_state" 1 120 prendre la valeur "endormr. 

Lorsque le resultat du test 1213 est negatif, au cours d'une 
operation 1215, I'unite centrale procede a I'analyse de la charge effective du 
reseau. A cet effet, I'unite centrale 206 comptabilise les periodes d'inactivite du 
moyen de communication, pour ajuster le nombre de paquets a emettre par 
canal virtuel, pour le trafic de priorite basse (c'est-a-dire en mode non 
connecte). 

En fonction du nombre d'intervalles de temps second aires non 
utilises pour la transmission effective de paquets, la bande passante est accrue, 
par incrementation de la valeur "spe^CP" 1112 dans la limite des bornes 
autorisees. 

Puis, le moyen de communication cesse ses emissions jusqu'a ce 
que le resultat du test 1202 devienne positif. 
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L'allocation ou la liberation d'un canal virtuel est effectuee par 

manipulation: 

- des listes 1101 et 1102, lors de I'execution des differentes 
etapes de gestion d'une connexion illustree en figure 4. 

- de la liste 1103, lors de la reception d'un message 
"SendSyncData_req" ou n SendAsyncData_cfr", par le moyen de 
communication, emis par le moyen de traitement, jusqu'a transmission 
complete du message. 

Ainsi, le moyen de controle de charge tient compte de la charge 
effective sur le reseau pour repartir les droits d'acces entre les differents 
niveaux de priorite. 

La figure 13 represente un organigramme de determination, par le 
noeud source, de disponibilite de chemin pour I'etablissement d'une connexion, 
ce qui correspond, en figure 4, a I'operation 302. 

Le moyen de communication prend en compte la description du 
service requis etabli par I'application ou le peripherique qui emet le message, 
au cours d'une operation 1302. 

Puis, le moyen de communication effectue le choix du canal virtuel 
et du chemin le plus disponible, au cours de I'operation 1304, en faisant usage 
de la table de routage. 

Au cours d'un test 1305, le moyen de communication du noeud 
source determine si un chemin a ete choisi au cours de I'operation 1304 ou 
non. 

Lorsque le resultat du test 1305 est negatif, le moyen de 
communication revendique I'arret de la procedure de mise en place de la 
connexion, au cours d'une operation 1306. Lorsque le resultat du test 1305 est 
positif, le moyen de communication effectue le calcul des parametres de 
transmission, en particulier de la bande passante, de la taille des paquets 
transmis, des taux (frequences d'emission) de paquets et de priorite de la 
communication correspondant au champ 1111 a 1113 illustres en figure 11, en 
faisant usage de la table de charge, au cours d'une operation 1303. 
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Puis, au cours d'une operation 1307, le moyen de communication : 

- alloue un canal virtuel en specifiant les parametres de 
transmission pr6cedemment calcules, et 

- fait varier la taille des paquets avec la charge du chemin ainsi 
5 que le taux de paquets sur ledit chemin, et 

- met a jour sa table de charge par I'intermediaire du moyen de 
controle de charge. 

Ensuite, au cours d'une operation 1308, il revendique la poursuite 
de la mise en place de la connexion 

1 0 L'operation 302 est alors terminee. 

La figure 14 represente un organigramme de determination, par 
un noeud intermediate ou le noeud destinataire, de disponibilite de chemin 
pour I'etablissement d'une connexion, ce qui correspond, en figures 5 et 6, aux 
operations 332 et 372. 

15 Le moyen de communication obtient, d'abord, la description du 

chemin et du service requis associes a la nouvelle connexion, en lisant le 
message 251 "set-up" provenant du noeud source (operation 305), au cours 
d'une op6ration 1402. 

Puis, le moyen de communication verifie la disponibilite du chemin 
20 en fonction du service requis, au cours de l'operation 1404, en faisant usage de 
la table de routage. 

Au cours d'un test 1405, le moyen de communication du noeud 
consid6re determine si le chemin est disponible au cours de l'operation 1404 ou 
non. 

25 Lorsque le resultat du test 1405 est negatif, le moyen de 

communication revendique la procedure de mise en place de la connexion, au 
cours d'une op6ration 1406. Lorsque le resultat du test 1405 est positif, le 
moyen de communication effectue le calcul des parametres de transmission, en 
particulier de la bande passante, de la taille des paquets transmis, des taux 

30 (frequence d'6mission) de paquet et de priorite de la communication, en faisant 
usage de la table de charge, au cours d'une operation 1403. 
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Puis, au cours d'une operation 1407, le moyen de communication 
met a jour sa table de charge par I'intermediaire du moyen de controle de 
charge, ce qui revient a reserver les ressources necessaires a la connexion 
envisagee, puis, au cours d'une operation 1408, il poursuit la mise en place de 
la connexion. A la fin de Tune des operations 1406 ou 1408, I'operation 334 est 
terminee. 

La mise a jour de la table de charge s'accompagne d'une mise a 
jour des parametres de transmissions associes aux canaux virtuels existants 
representatifs du trafic sortant pour le noeud considere, a travers la valeur des 
champs 1111 a 1113 pour le trafic connecte et 1111, 1113, 1115, 1116 pour le 
trafic non connecte. 

La figure 15 represents un organigramme de determination, par 
un noeud voisin, de disponibilite de chemin pour I'etablissement d'une 
connexion, ce qui correspond, en figure 7, aux operations 413. 

Le moyen de communication obtient, d'abord, la description du 
chemin et du service requis associes a la nouvelle connexion, en lisant le 
message 253 "LinkTabLoad" provenant du noeud source (operation 313), au 
cours d'une operation 1502. 

Ensuite, le moyen de communication effectue le choix des 
parametres de transmission, en particulier de la bande passante, de la taille des 
paquets transmis, des taux de paquet et de priorite de la communication, en 
faisant usage de la table de charge, au cours d'une operation 1503. Puis, au 
cours d'une operation 1504, le moyen de communication met a jour sa table de 
charge. A la fin de I'operation 1504, le fonctionnement de mise en place de la 
connexion, par le noeud voisin, est termine. 
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REVENDICATIONS 

1. Procede cle communication sur un reseau, caracterise en ce qu'il 
comporte, pour I'etablissement d'une connexion : 

A/ effectuees par un dispositif de communication source 
5 d'information a transmettre en mode connecte (801 ) : 

- une operation de determination (1302) de besoin de bande 
passante pour la transmission de ladite information en mode connecte, 

- une operation de determination d'un eventuei chemin disponible 
pour ladite transmission (1304), en fonction d'informations conservees dans une 

10 table de charge de chaque lien du reseau, et 

- lorsqu'un chemin disponible est determine : 

• une operation de transmission (305) d'une information 
representative dudit besoin de bande passante (251) a 
destination du dispositif de communication suivant sur ledit 

15 chemin (803), et 

• une operation de mise a jour (1307) de ladite table de 
charge des liens du reseau, 

- une operation de diffusion a destination d'au moins tous les 
dispositifs de communication en dehors du chemin (805 a 809), d'une information 

20 representative dudit besoin de bande passante (253), 

B/ effectuees par chaque dispositif de communication intermediate 
(803, 804) sur ledit chemin : 

- une operation de determination de disponibilite dudit chemin 
(1404), pour ladite communication, en fonction d'informations conservees dans 

25 une table de charge de chaque lien du reseau, et 

- lorsque le chemin est disponible : 

• une operation de transmission (336) d'une information 
representative dudit besoin de bande passante, au 
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dispositif de communication suivant sur le chemin (804, 
802), et 

• une operation de mise a jour de la table de charge (1407) 
des liens du reseau, 

5 CI effectuee par chaque dispositif de communication en dehors 

dudit chemin (805 a 809) : 

- une operation de mise a jour d'une table de charge des liens du 
reseau (1504). 

2. Procede de communication selon la revendication 1 , caracterise 
en ce que, au cours de I'operation de transmission (305) dudit besoin de bande 
passante (251) a destination du dispositif de communication suivant sur ledit 
chemin, le dispositif de communication source (801) transmet une information 
representative d'un service requis pour ladite transmission en mode connects. 

3. Procede de communication selon la revendication 2, caracterise 
en ce qu'il comporte, effectuee par chaque dispositif de communication du reseau 
(801 a 809), une operation de determination de parametres de communication 
(1303, 1403, 1503) dependant du service requis, et en ce que I'operation de mise 
a jour des tables (1307, 1407, 1504) est effectuee en prenant en compte lesdits 
parametres. 

4. Procede de communication selon Tune quelconque des 
revendications 1 a 3, caracterise en ce qu'il comporte, a la fin de la transmission 

25 en mode connects : 

- effectuee par un dispositif de communication source d'information 
transmise en mode connect6, une operation de diffusion (320) d'une information 
repr6sentative du relachement de la connexion (256), a destination de tous les 
autres dispositifs de communication du reseau (802 & 809), et 
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- effectuee par chaque dispositif de communication dudit reseau, 
une operation de mise a jour d'une table de charge des liens du reseau. 

5. Procede de communication selon Tune quelconque des 
5 revendications 1 a 4, caract6rise en ce que, au cours de I'etabHssement d'une 
connexion, I'operation de diffusion (313) a destination d'au moins tous les 
dispositifs de communication en dehors du chemin, d'une information 
representative dudit besoin de bande passante, est effectuee apres que chaque 
dispositif de communication dudit chemin ait effectue : 

10 - une operation de determination de disponibilite dudit chemin, pour 

ladite communication, en fonction d'informations conservees dans une table de 
charge de chaque lien du reseau, et 

- lorsque le chemin est disponible : 

• une operation de transmission dudit besoin de bande 
15 passante, au dispositif de communication suivant sur le 

chemin, et 

• une operation de mise a jour d'une table de charge des 
liens du reseau. 



20 6. Procede de communication selon Tune quelconque des 

revendications 1 a 5, caracterise en ce qu'il comporte, au cours de I'etabHssement 
d'une connexion, effectuee par le dispositif de communication source, une 
operation de determination de I'integralite du chemin (1304) destine a etre suivi 
par Pinformation a transmettre en mode connecte. 

25 

7. Procede de communication selon Tune quelconque des 
revendications 13 6, caracteris6 en ce que, au cours de I'operation de 
transmission (305) d*une information representative dudit besoin de bande 
passante a destination du dispositif de communication suivant sur ledit chemin 
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(251), le dispositif de communication source transmet une information 
representative dudit chemin. 

8. Procede de communication selon Tune quelconque des 
5 revendications 1 a 7, caracterise en ce que, au cours de I'operation de diffusion 

(313), Tinformation representative dudit besoin de bande passante suit un arbre 
de recouvrement du reseau dont au moins la moitie des feuilles sont des 
dispositifs de communication intermediates ou le dispositif de communication 
destinataire, surle chemin associe a la connexion. 

10 

9. Procede de communication selon Tune quelconque des 
revendications 1 a 8, caracterise en ce que, au cours de Poperation de diffusion 
(313), Tinformation representative dudit besoin de bande passante est diffusee 
avec une information representative de I'integralite du chemin associe a ladite 

1 5 connexion. 



10. Procede de communication selon Tune quelconque des 
revendications 1 a 9, caracterise en ce que chaque table de charge comporte, 
pour chaque lien du reseau, une reference (1 120) concemant chaque chemin qui 
20 comporte ledit lien et qui est associe a une connexion. 



11. Procede de communication selon la revendication 10, 
caracterise en ce qu'a chaque lien du reseau est associee une information 
representative de la bande passante disponible sur ledit lien. 

25 

12. Procede de communication selon Tune quelconque des 
revendications 1 a 1 1 , caracterise en ce que chaque table de charge comporte, 
pour chaque chemin, une reference concemant chaque lien qu'il comporte. 
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13. Procede de communication selon la revendication 12, 
caracterise en ce qu'a chaque chemin est associee une information 
representative de la bande passante disponible sur ledit chemin. 

5 14. Procede de communication selon les revendications 11 et 13, 

caracterise en ce que ('information representative de bande passante disponible 
sur ledit chemin est egale a rinformation de bande passante disponible sur le lien 
le moins disponible dudit chemin. 



10 15. Procede de communication selon Tune quelconque des 

revendications 11 a 14, caracterise en ce que, au cours de I'operation de 
determination de chemin (1304), le chemin choisi est le chemin dont la 
disponibilite est la plus elevee. 

15 16. Procede de communication selon Tune quelconque des 

revendications 1 a 15, caracterise en ce qu'il cornporte, effectuee par le dispositif 
de communication source, une operation de determination de taille du paquet 3 
transmettre sur le reseau (1 221 ), prenant en compte la charge sur ledit reseau. 

20 17. Procede de communication selon Tune quelconque des 

revendications 1 a 16, caracterise en ce qu'il cornporte, effectuee par le dispositif 
de communication source, une operation de determination de frequence 
d'emission de paquets a transmettre sur le reseau (1221), prenant en compte la 
charge sur ledit reseau. 

25 

18. Procede selon Tune quelconque des revendications 1 a 17, 
caracterise en ce que chaque dispositif de communication effecfue chaque 
transmission d'information par commutation de paquet. 

30 19. Procede de communication selon Tune quelconque des 

revendications 1 £ 18, entre des dispositifs de communication susceptibles, de 



4 



53 



determiner, chacun, pour chaque information qu'il a a transmettre, un chemin a 
lui faire suivre, caracterise en ce qu'il comporte : 

- effectuee par chaque dispositif de communication dit "source", 
qui a besoin d'une connexion associee a un chemin, pour effectuer une 

5 transmission d'information a destination d'un dispositif de communication 
destinataire, une operation de demande de connexion, au cours de laquelle, le 
dispositif de communication source transmet, a destination de chaque dispositif 
de communication dudit chemin, une demande d'etablissement de connexion, 

- lorsque I'etablissement de ladite connexion est possible, 
10 effectuee par au moins le dispositif de communication destinataire, une 

operation d'emission a destination du dispositif de communication source d'une 
acceptation de connexion, 

- effectuee par le dispositif de communication source, une 
operation de diffusion, a tous les dispositifs de communication du reseau, d'une 

15 information representative de I'etablissement de la connexion, 

- effectuee par chaque dispositif de communication dudit chemin, 
a reception de ladite information representative d'etablissement de connexion, 
une operation de confirmation d'etablissement de ladite connexion, et 

- effectuee par chaque dispositif de communication en dehors 
20 dudit chemin, a reception de ladite information representative d'etablissement 

de connexion, une operation de mise en memoire d'une information 
representative de ladite connexion. 



20. Dispositif de communication sur un reseau, caracterise en ce 

25 que : 

- il comporte une memoire (204A) adaptee a conserver une table de 
charge contenant des informations relatives a la charge de chaque lien du reseau, 
et 

- il est adapt§, pour I'etablissement d'une connexion destinee a la 
30 transmission d'information en mode connects : 
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• a determiner un besoin de bande passante pour la 
transmission de ladite information en mode connecte, 

• a determiner un eventuel chemin disponible pour ladite 
transmission, en fonction d'informations conservees dans 

5 ladite table de charge, 

et lorsqu'un chemin disponible est determine, 

• a transmettre une information representative dudit besoin de 
bande passante, a destination du dispositif de 
communication suivant sur ledit chemin, 

10 • a mettre a jour ladite table de charge, 

• a diffuser, a destination d'au moins tous les dispositifs de 
communication en dehors du chemin, une information 
representative dudit besoin de bande passante. 



15 21. Dispositif de communication selon la revendication 20, 

caracterise en ce qu'il est adapte, lorsqu'il regoit, de la part d'un dispositif de 
communication source, une information representative d'un besoin de bande 
passante, associee a une information representative d'un chemin sur lequel il se 
trouve : 

20 - a determiner la disponibilite dudit chemin, pour ladite 

communication, en fonction d'informations conservees dans ladite table de charge 
de chaque lien du reseau, 

et lorsque le chemin est disponible 

- a transmettre une information representative dudit besoin de 
25 bande passante, a destination du dispositif de communication suivant sur ledit 

chemin, 

- & mettre & jour ladite table de charge. 
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22. Dispositif de communication selon Tune quelconque des 
revendications 20 ou 21 , caracterise en ce qu'il est adapte, lorsqu'il resort une 
information representative d'un besoin de bande passante, associee a une 
information representative d'un chemin sur lequel il ne se trouve pas, a mettre a 

5 jour ladite table de charge. 

23. Dispositif de communication selon Tune quelconque des 
revendications 20 a 22, caracterise en ce qu'il est adapte, pour transmettre ledit 
besoin de bande passante a destination du dispositif de communication suivant 

10 sur ledit chemin, a transmettre une information representative d'un service requis 
pour ladite transmission en mode connecte. 

24. Dispositif de communication selon la revendication 23, 
caracterise en ce qu'il comporte un moyen de determination de parametres de 

15 communication dependant du service requis, et en ce qu'il est adapte a mettre a 
jour la table de charge en prenant en compte lesdits parametres. 

25. Dispositif de communication selon Tune quelconque des 
revendications 20 a 24, caracterise en ce qu'il est adapte, pour mettre fin a une 

20 transmission en mode connecte, a diffuser une information representative du 
relachement de la connexion, a destination de tous les dispositifs de 
communication du reseau, afin que chaque dispositif de communication dudit 
reseau mette a jour une table de charge des liens du reseau. 

25 26. Dispositif de communication selon Tune quelconque des 

revendications 20 £ 25, caracterise en ce qu'il est adapte, pour I'etablissement a 
determiner Pintegralite du chemin destine a etre suivi par reformation & 
transmettre en mode connecte. 
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27. Dispositif de communication selon i'une quelconque des 
revendications 20 a 26, caracterise en ce que, pour transmettre une information 
representative dudit besoin de bande passante a destination du dispositif de 
communication suivant sur ledit chemin, il est adapte a transmettre une 

5 information representative dudit chemin. 

28. Dispositif de communication selon Tune quelconque des 
revendications 20 3 27, caracterise en ce qu'il est adapte a faire suivre a 
rinformation representative dudit besoin de bande passante un arbre de 

10 recouvrement du reseau dont au moins la moitie des feuilles sont des dispositifs 
de communication intermediates ou le dispositif de communication destinataire, 
sur le chemin associe a la connexion. 

29. Dispositif de communication selon Tune quelconque des 
15 revendications 20 a 28, caracterise en ce qu'il est adapte a diffuser, avec 

Pinformation representative dudit besoin de bande passante, une information 
representative de I'integralite du chemin associe a ladite connexion. 

30. Dispositif de communication selon Tune quelconque des 
20 revendications 20 a 29, caracterise en ce que ladite memoire est adaptee a 

conserver, dans chaque table de charge, pour chaque lien du reseau, une 
reference concernant chaque chemin qui comporte ledit lien et qui est associe a 
une connexion. 

25 31. Dispositif de communication selon la revendication 30, 

caracterise en ce que ladite memoire est adaptee a conserver, dans ladite table 
de charge, pour chaque lien du r6seau, une information representative de la 
bande passante disponible sur ledit lien. 



»S aysnt red 1 . 



10 



57 



32. Dispositif de communication selon Tune quelconque des 
revendications 20 a 31, caracterise en ce que ladite memoire est adapt6e a 
conserver, dans chaque table de charge, pour chaque chemin, une reference 
concemant chaque lien qu'il cornporte. 

33. Dispositif de communication selon la revendication 32, 
caracterise en ce que ladite memoire est adaptee a conserver, dans chaque table 
de charge, assoctee a chaque chemin, une information representative de la bande 
passante disponible sur ledit chemin. 



34. Dispositif de communication selon les revendications 31 et 33 , 
caracterise en ce que ladite memoire est adaptee a conserver, dans chaque table 
de charge, une information representative de bande passante disponible sur ledit 
chemin egale 3 reformation de bande passante disponible sur le lien le moins 
1 5 disponible dudit chemin. 



35. Dispositif de communication selon Tune quelconque des 
revendications 32 a 35, caracterise en ce qu'il est adapte, pour determiner une 
chemin, a choisir le chemin dont la disponibilite est la plus elevee. 

20 

36. Dispositif de communication selon Tune quelconque des 
revendications 20 a 35, caracterise en ce qu'il cornporte un moyen de 
determination de taille du paquets a transmettre sur le reseau adapte a prendre 
en compte la charge sur ledit reseau. 

25 

37. Dispositif de communication selon Tune quelconque des 
revendications 20 3 36, caract6ris6 en ce qu'il cornporte un moyen de 
determination de frequence d'emission de paquets d transmettre sur le r6seau 
adapte a prendre en compte la charge sur ledit reseau. 
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38. Dispositif selon Tune quelconque des revendications 20 a 37, 
caracterise en ce qu'il est adapte a effectuer chaque transmission d'information 
par commutation de paquet 



5 39. Dispositif de communication selon Tune quelconque des 

revendications 20 a 38, sur un reseau comportant des dispositifs de 
communication susceptibles, chacun, de determiner le chemin a faire suivre & 
chaque information qu'il a a transmettre, caracterise en ce qu'il est adapte, 
lorsqu'il a besoin d'une connexion assoctee a un chemin, pour effectuer une 
10 transmission d'information a destination d'un dispositif de communication 
destinataire : 

- a faire transmettre, par le moyen de transmission, a destination 
de chaque dispositif de communication dudit chemin, un message de demande 
d'etablissement de connexion, et 
15 - a reception d'un message d'acceptation de connexion en 

provenance du dispositif de communication destinataire, a faire diffuser, par 
ledit moyen de transmission, a tous les dispositifs de communication du reseau, 
un message d'information d'etablissement de la connexion. 

20 40. Ordinateur, caracterise en ce qu'il comporte un dispositif de 

communication selon Tune quelconque des revendications 20 & 39 

41. Camera, caracterisee en ce qu'elle comporte un dispositif de 
communication selon Tune quelconque des revendications 20 a 39. 

25 

42. Telecopieur, caracterise en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 20 a 39. 

43. Appareil photographique, caracterise en ce qu'il comporte un 
30 dispositif de communication selon Tune quelconque des revendications 20 a 39. 
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44. Televiseur, caracterise en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 20 a 39. 

45. Imprimante, caract6ris6e en ce qu'elle comporte un dispositif 
5 de communication selon Tune quelconque des revendications 20 a 39. 

46. Scanner, caracterise en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 20 a 39. 



10 47. Lecteur audio/video, caracterise en ce qu'il comporte un 

dispositif de communication selon Tune quelconque des revendications 20 a 39. 
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32. Dispositif cle communication selon Tune quelconque des 
revendications 20 ^ 31, caracterise en ce que ladite memoire est adaptee a 
conserver, dans chaque table de charge, pour chaque chemin, une reference 
concemant chaque lien qu'il comporte. 

5 

33. Dispositif de communication selon la revendication 32, 
caracterise en ce que ladite memoire est adaptee £ conserver, dans chaque table 
de charge, associ6e a chaque chemin, une information representative de la bande 
passante disponible sur ledit chemin. 

10 

34. Dispositif de communication selon les revendications 31 et 33 , 
caracterise en ce que ladite memoire est adaptee a conserver, dans chaque table 
de charge, une information representative de bande passante disponible sur ledit 
chemin egale a rinformation de bande passante disponible sur le lien le moins 

1 5 disponible dudit chemin. 



35. Dispositif de communication selon Tune quelconque des 
revendications 32 & 34, caracterise en ce qu'il est adapte, pour determiner une 
chemin, a choisir le chemin dont la disponibilite est la plus elevee. 

20 

36. Dispositif de communication selon Tune quelconque des 
revendications 20 a 35, caracterise en ce qu'il comporte un moyen de 
determination de taille du paquets a transmettre sur le reseau adapte £ prendre 
en compte la charge sur ledit reseau. 

25 

37. Dispositif de communication selon Tune quelconque des 
revendications 20 3 36, caracterise en ce qu'il comporte un moyen de 
determination de frequence demission de paquets a transmettre sur le r6seau 
adapte d prendre en compte la charge sur ledit reseau. 
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